Automatic websocket reconnect and reload handling#5805
Conversation
This allows the app to be more resilient in the face of websocket reconnects. The event is processed against a token, so there's no reason to maintain websocket affinity for event processing. Whenever the update is ready to send, it will be sent to the current websocket/sid associated.
* ensureSocketConnected is called when adding events or pumping the queue to trigger an automatic reconnection to the backend * when "reload" event is encountered, trigger a re-hydrate and wait until ALL on_load have finished processing and `is_hydrated` is True before requeue the event that caused the "reload"
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Greptile Summary
This PR introduces automatic websocket reconnection functionality and enhanced reload event handling to improve the resilience of Reflex applications against network interruptions. The changes are focused entirely on the client-side JavaScript state management system.
The core enhancement adds an ensureSocketConnected() function that automatically detects when the websocket connection is lost and attempts to re-establish it. This function is strategically called before adding events to the queue and before processing the event queue, ensuring operations don't fail due to a dropped connection. When the socket disconnects, socket.current is now explicitly set to null, which enables the automatic reconnection logic.
A significant improvement is the introduction of an on_hydrated_queue mechanism that handles reload events more robustly. Previously, reload events could be processed before the application state was fully initialized, causing race conditions. Now, when a "reload" event is encountered, it triggers a re-hydration process and queues the reload event until all on_load handlers have finished processing and is_hydrated is True. This ensures the application is in a consistent state before processing reload events.
The visibility change handler has also been enhanced to recreate the socket connection when the user returns to a tab and finds the socket is null, improving recovery from browser tab switching scenarios.
These changes integrate seamlessly with Reflex's existing event system and state management architecture, maintaining backward compatibility while significantly improving user experience during network disruptions or server restarts.
Confidence score: 4/5
- This PR is generally safe to merge with good resilience improvements but introduces some complexity in connection state management
- Score reflects solid implementation of reconnection logic but potential edge cases around connection state transitions and queue management
- Pay close attention to the websocket connection state management and the new
on_hydrated_queuelogic to ensure no race conditions
1 file reviewed, 1 comment
|
|
||
| // When the socket disconnects reset the event_processing flag | ||
| socket.current.on("disconnect", () => { | ||
| socket.current = null; // allow reconnect to occur automatically |
There was a problem hiding this comment.
style: Setting socket to null on disconnect enables automatic reconnection, but ensure this doesn't cause issues with concurrent access to socket.current in other parts of the codebase
CodSpeed Performance ReportMerging #5805 will not alter performanceComparing Summary
|
It doesn't really work, because the frontend will only process one non-background event at a time, so the disconnect ends up occuring after the event handler is already done.
2 participants
is_hydratedis True before requeue the event that caused the "reload"