## Context
Record tables subscribe to SSE with their query signature (object +
filter) and the server pushes only matching DB events.
`isQueryMatchingObjectRecordEvent` evaluated `after ?? before` — for
UPDATED events that is always `after`, so an update moving a record
**out** of a filtered view never matched: no event, and the open table
keeps the stale row until a manual reload.
Symptom on twenty-internal: a Sales Action Item marked Done by an
AI-chat tool (or any API/workflow write) stays visible in the `status =
OPEN` view. Records *entering* a view appear live; records *leaving*
never disappear. UI edits mask the bug via the local Apollo cache.
## Fix
For UPDATED events, view membership now matches on either snapshot (a
before-only match = the record just left the view). Row-level
authorization is unchanged: still evaluated against the delivered
snapshot, so a before-state match cannot authorize a payload the
subscriber lost RLS access to.
A pre-existing, unrelated payload leak spotted during review (before
values delivered when a record enters RLS scope) is fixed separately in
the stacked #23870.
## Test plan
- Unit: leave-view update publishes (fails on the old matcher —
verified), neither-state-matches does not, RLS-failing delivered state
does not even when before matched. 36/36 on the spec, full server suite
green.
- End-to-end on a local stack: companies table filtered `Name contains
'Open'`, `updateCompany` renamed a row out of the filter via the API →
row disappeared from the open table within seconds, no reload.
Charles Bochet
a47f566eb1