fix: deliver linked state updates to all clients - #6934
Conversation
Greptile SummaryThis PR extends shared-state fan-out to clients connected through other backend instances and strengthens Redis token ownership reconciliation.
Confidence Score: 4/5The PR is not yet safe to merge because an ownership transition between the connectivity check and update emission can still cause a linked client to miss its state update. The shared-state task checks connectivity before entering the state-update path, while emission later resolves routing independently; a client that moves backend instances in that interval can still have the delta sent using stale ownership. Files Needing Attention: reflex/istate/shared.py
|
| Filename | Overview |
|---|---|
| reflex/istate/shared.py | Cross-instance fan-out now checks distributed connectivity, but the check remains separate from eventual update routing, leaving the previously reported ownership-change race outstanding. |
| reflex/utils/token_manager.py | Adds distributed connectivity checks and conditional ownership recovery while addressing the previously reported stale-cache and delayed-deletion paths. |
| tests/units/istate/test_shared.py | Adds focused coverage for local and cross-instance shared-state fan-out. |
| tests/units/utils/test_token_manager.py | Adds regression coverage for disconnect ordering, stale ownership records, delayed notifications, and conditional restoration. |
Reviews (8): Last reviewed commit: "wip" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Merging this PR will not alter performance
Comparing 
Footnotes
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Disconnects pop the local mapping before touching redis, so a self-owned record still present when a del notification arrives was created by a newer link and refers to a live socket. Re-store it instead of dropping it, which previously broke linked-update delivery for clients that relinked before the notification was processed.
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
…claims The keep-alive restore in _handle_socket_record_del is only legitimate when the key is genuinely gone. A plain SET could overwrite a record written meanwhile by another instance claiming the expired token, or by a concurrent relink on this instance. With NX, any newer write wins, and a wrongful delete of an owned key self-heals via the del notification.
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
2 participants
Uh oh!
There was an error while loading. Please reload this page.