[FarhanAliRaza]

Related to #7248. Pairs with #7412.

Problem

A foreground handler can change state after its last yield, for example in an except asyncio.CancelledError block when a supersedes=True call cancels it, or just before it raises. Nothing sends those changes to the frontend.

• Memory and disk send them late, with the next handler's first delta. The next handler gets the same state object, and that object still marks the vars as dirty.
• Redis without a cached lease (the default, REFLEX_OPLOCK_ENABLED=False) never sends them. The next handler unpickles a fresh copy, and _init_bookkeeping clears the dirty marks. The frontend shows the old value until the var changes again or the page reloads.

Fix

When process_event raises or is cancelled, _execute_event flushes the delta with chain_updates(None, root_state=...) before the exception propagates. The flush runs under the state lock, so it reaches the frontend before any delta from the next handler. If the flush fails, it is logged and the handler's own exception propagates. The background branch uses the same pattern.

Background handlers are not changed. They already flush in their finally.

Tests

• test_failed_handler_emits_writes_after_last_yield: memory, disk and redis, each cancelled and raising. All 6 cases fail on main and pass with the fix.
• test_failed_handler_flush_error_keeps_handler_exception: a computed var makes the flush fail. The handler's RuntimeError is reported and the flush error is logged. It fails when the except in _flush_failed_handler is removed.

Notes

• On Redis without fix(state): persist cancelled redis handler updates #7412, the frontend now receives these changes, but Redis still drops them. fix(state): persist cancelled redis handler updates #7412 fixes the storage side.
• fix(state): persist cancelled redis handler updates #7412 adds a docs sentence in docs/events/yield_events.md about this late delivery. Remove that sentence after this PR merges.

[cubic-dev-ai]

No issues found across 3 files

_{View guided diff | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge, with the existing non-blocking cancellation-test concern still open.

Findings

1.  Cancellation test skips completion ▶

Summary

Sends state changes made by a foreground handler before it fails or is cancelled.

• Foreground handlers send their final state writes when they fail.

_{Reviews (2) · Last reviewed commit: "Merge remote-tracking branch 'upstream/m..." · Reviewed by Greptile}

[greptile-apps]

Cancellation test skips completion

future.cancel() has already completed the future, so wait_all() raises immediately instead of waiting for the running handler. Leaving the processor context then starts shutdown, which can cancel the task again if its flush suspends. The test therefore does not establish that normal cancellation sends cleanup before shutdown.

Wait for a handler-completion signal or a following event before leaving the context, then check the delta.

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 18 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 148 untouched benchmarks

---

_{Comparing FarhanAliRaza:farhan/flush-delta-on-failed-handler (4fd54f2) with main (df3eb52)}