[kr1shna-exe]

Summary

Fixes #7248.

When a foreground handler is cancelled by a superseding event, Redis can discard every state change it made before cancellation, including updates already yielded to the client. The replacement handler then reads the old state. Preserve those changes before releasing the Redis lock so the replacement sees the same history as it does with in-memory state.

What changed

• Share cancellation-aware persistence across the three non-cached Redis locking paths. Save under the existing lock fence and re-raise cancellation afterward.
• Cover root and substate writes, handler cleanup, cached leases, expired locks and non-cancellation exceptions.
• Exercise superseding handlers through the event processor and check both stored state and emitted deltas. Document the behavior and add a news fragment.

Verification

• Reproduced three failing manager cases and the failing Redis event-processor case before the fix using an isolated Redis server.
• uv run pytest tests/units --cov --no-cov-on-fail --cov-report=: 11,193 passed, 155 skipped; 78.68% coverage.
• Redis manager tests against real Redis: 27 passed. Event-processor regression with real Redis and the in-memory control: 2 passed.
• uv run ruff check ., uv run ruff format --check . and uv run pyright reflex tests passed.
• All pre-commit hooks applicable to the five changed files passed.
• All-files pre-commit passed formatting, lint, spelling, stub generation and generated-source checks. Its Pyright hook found six existing macOS CPU-affinity errors in unchanged benchmark files; those files pass with --pythonplatform Linux, matching CI. The remaining ty and Biome hooks passed separately.

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issues were found.

Summary

Preserves cancelled foreground handlers’ Redis state before releasing their locks.

• Redis keeps a cancelled handler’s state for the next event.

The earlier unnumbered thread was manually resolved without explanation. The current shielded save also addresses its concern about a second cancellation interrupting the write.

No new actionable issues were found. Tests were inspected, not run.

_{Reviews (3) · Last reviewed commit: "Merge main into fix/7248-persist-cancell..." · Reviewed by Greptile}

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 19 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 kr1shna-exe:fix/7248-persist-cancelled-state (3f1677e) with main (aeaac72)}

[FarhanAliRaza]

Please add one sentence here: a write the cancelled handler makes after its last yield (for example in its except asyncio.CancelledError cleanup) is stored, but the frontend receives it only with a later update that touches the same var.

Evidence: the disk and memory managers keep the dirty-var bookkeeping on the live state object, so the replacement handler's next delta carries that write. Redis rebuilds the bookkeeping on unpickle (_init_bookkeeping in __setstate__), so the replacement handler's delta does not include it.

Repro: a @rx.event(supersedes=True) handler sets self.entries before the yield and sets Child.last_cancelled only in its except asyncio.CancelledError block. After the replacement handler completes on Redis, the page shows entries with the cancelled handler's values, but Child.last_cancelled stays empty until a page reload. The same app on the disk state manager shows Child.last_cancelled right away.

---

Generated by Claude Code