Backport #32953 to 2.0: stop a single unevaluable event from discarding its whole change-event batch

[manerow]

Backport of #32953 (Fixes #31331) to 2.0.

Problem

Alert filters on owners or domains re-read the entity from the database. Some entity types, such as user and domain, do not have an owners or domains field, so that read throws Invalid field name. The exception escapes the filter, and the consumer still moves its offset forward, so every other event in the same batch is silently dropped: no delivery, no retry, no failed-event record. While such an event is unprocessed, /diagnosticInfo for the alert also returns 500.

#32953 fixes this on main in two ways: filters skip the read when the entity type cannot have the field, and an event whose filters still fail is excluded on its own instead of taking the batch down with it.

Why a manual backport

#32953 had no To release label, so no automatic pick was attempted. The cherry-pick has three conflicts, all caused by earlier main changes that 2.0 does not have:

• Scheduler, event parsing: main reads events with ChangeEventJsonUtils.readOrNull (from fix(alerts): retire the nine EventType values no emitter produces #33033). Here the existing JsonUtils.readValue stays and only the filter call changes.
• Rule evaluator, thread subject: main renamed threadSubject() to feedSubject() in Fixes #30908: Add Conversation V2 and activity replies #30909. The new helper calls threadSubject() here.
• AlertsRuleEvaluatorTestSuiteDomainTest: this test file came with Fixes #30908: Add Conversation V2 and activity replies #30909 and does not exist on 2.0, so its update is dropped.

Apart from those three adaptations, the added and removed lines match #32953 exactly, plus one review follow-up: getFilteredEvents keeps its original stream instead of the loop #32953 introduced. The same change goes to main in #33287, so both branches stay identical. The changed AlertUtil methods are additions only, and nothing in Collate 2.0 calls them.

Could the resolutions change existing behaviour?

The new check skips a read only when the entity's schema lacks the field. The read itself validates fields against that same list and throws for exactly those fields. So nothing that reads successfully today is skipped.

How it was tested

• spotless:check clean; 100/100 unit tests green across the alert filter, event consumer and subscription scheduler tests, including the two new test classes.
• Deployed locally on a fresh 2.0.2 stack. Three alerts on all: domain Finance, owner admin, and domain Marketing as a control. Each scenario wrote an event the filter cannot evaluate and a matching table event back to back, so both land in one batch:

Scenario	This PR	2.0 without it
domain update + table update (domain filter)	delivered	lost (Batch Size : 2 error)
user update + table update (owner filter)	delivered	lost
thread about a domain + thread about the table (domain filter)	delivered	lost
thread about a user + thread about the table (owner filter)	delivered	lost
Marketing control alert	0 events	0 events
/diagnosticInfo during the batch	200 on all 284 calls	~30% returned 500

In the run without this PR, the thread scenarios failed inside threadSubjectMatchesDomain and threadSubjectMatchesOwner, the code changed by the conflict resolution. With it, both delivered threads were the ones about the table.

Not in this PR

On 2.0, a domain filter on a test case never falls back to its test suite's domain, because the suites are taken from the event payload, which carries no domains. main fixed that inside #30909, so the dropped test cannot pass here with or without this change. It is a separate, pre-existing issue.

[github-actions]

✅ Playwright Results — workflow succeeded

Validated commit a48b0267b1df08f6147a413a773fcd5ad782dc28 in Playwright run 34883736393, attempt 1.

✅ 795 passed · ❌ 0 failed · 🟡 1 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky

Performance

Blocking targets: ✅ met · Optimization targets: 🟡 in progress

Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting.

🕒 Full workflow signal wall (to summary) 50m 25s

⏱️ Max setup 2m 57s · max shard execution 18m 48s · max shard-job elapsed before upload 21m 44s · reporting 4s

🌐 206.53 requests/attempt · 2.62 app boots/UI scenario · 23.76% common-shard skew

Optimization targets still in progress:

• Common shard skew was 23.76% (convergence target: at most 15%).
• Browser traffic was 206.53 requests per attempt (convergence target: fewer than 200).
• Application boot ratio was 2.62 per UI scenario (2175 boots / 829 scenarios; convergence target: at most 1).

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky
✅ Shard chromium-01	147	0	0	0	0	0
🟡 Shard chromium-02	144	0	1	0	0	0
✅ Shard chromium-03	167	0	0	0	0	0
✅ Shard chromium-04	145	0	0	0	0	0
✅ Shard data-asset-rules-01	65	0	0	0	0	0
✅ Shard domain-isolation-01	16	0	0	0	0	0
✅ Shard global-state-01	34	0	0	0	0	0
✅ Shard ingestion-01	32	0	0	0	0	0
✅ Shard reindex-01	5	0	0	0	0	0
✅ Shard search-01	11	0	0	0	0	0
✅ Shard search-rbac-01	29	0	0	0	0	0

🟡 1 flaky test(s) (passed on retry)

• Pages/Entity.spec.ts › Tag and Glossary Term preservation in column detail panel (shard chromium-02, 1 retry)

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace

[gitar-bot]

Code Review ✅ Approved

Backport of #32953 to 2.0 that stops a single unevaluable event from discarding its whole change-event batch. Filters now skip reads when the entity type cannot have the field, and events whose filters fail are excluded individually instead of taking the batch down. Manually resolved three conflicts from earlier main changes not present in 2.0. No issues found.

Review coverage

Rules No rules evaluated

Functional validation Not enabled · Set up

Auto-approval Not enabled · Set up

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}