Tenant feed filters is_ignored / is_remediated only support inclusion (true), not exclusion (false)

[n3tl0kr]

Path: /api-reference/v4/endpoints/current-tenant-feed
Endpoint: POST /firework/v4/events/tenant/_search

The tenant feed documents filters.is_ignored and filters.is_remediated as booleans. In practice, only true changes results. false (or omitting the keys) returns the same event set as an unfiltered status query. That forces clients to paginate through already-ignored/remediated events and filter client-side, which is costly at the 10-results-per-page cap.

Expected behavior

Per the OpenAPI FeedFilters schema (is_ignored / is_remediated, default false), we expected:

{
  "size": 10,
  "order": "asc",
  "from": null,
  "filters": {
    "estimated_created_at": { "lte": "2020-06-01T00:00:00Z" },
    "is_ignored": false,
    "is_remediated": false
  }
}

to return only New events (not ignored, not remediated) within the date window.

Actual behavior

is_ignored: false and is_remediated: false do not narrow results. The first page matches a date-only query: remediated and ignored events are still returned alongside New events.

Also tested ignored / remediated (without the is_ prefix). No change.

Setting is_ignored: true or is_remediated: true does filter as documented (inclusion only).

Impact

For bulk backlog cleanup (remediate/ignore thousands of old tenant events):

• Each scroll page can be mostly already-processed events.
• At size max 10, page count scales with total historical volume, not actionable volume.
• Client-side status filtering is required, adding latency and API quota use.

Example: ~2,900 actionable New events required ~380 scroll pages (~3,800 raw rows) because ~800+ ignored/remediated rows in the same date window were still returned by the API.