Repository navigation
Fix stale on_load during websocket connection - #7522
Conversation
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Reply with feedback, questions, or to request a fix.
View guided diff | Re-trigger cubic
[Medium impact] The PR appears safe to merge; no new actionable issues were found. SummaryThe PR builds the first websocket hydration event from the route current when the connection begins.
Reviews (8) · Last reviewed commit: "fix: keep the last queued on_load after ..." · Reviewed by Greptile |
…7487-stale-on-load # Conflicts: # packages/reflex-base/src/reflex_base/.templates/web/utils/state.js
Merging this PR will not alter performance1 warning
Comparing |
# Conflicts: # packages/reflex-base/src/reflex_base/.templates/web/utils/state.js # tests/units/compiler/state_js.test.mjs
Every queued on_load_internal loads the route current when it is sent, so keeping all of them ran the new page's on_load once per navigation made during the websocket handshake. Keep only the first one, in its queue position, when the route changed after the auth event was built.
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
View guided diff | Re-trigger cubic
Each navigation queues the browser storage it read, then its on_load. Keeping the first queued on_load ran the page's handlers before a later navigation's storage update. Keep the last one instead, so the handlers see the newest storage values.
Fixes #7487. The websocket’s initial hydration event now uses the route current when the connection begins, preventing navigation during connection setup from running the previous page’s
on_loadhandler or triggering its redirect.Coalesces queued internal
on_loadevents when the hydration event already covers the current route. Adds unit and dev/production browser regression tests.