You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
White screen at initial start manager or app #3526
When a user logs in into the manager or an app (O*****d) sometimes it displays a white screen. Only SHIFT-REFRESH resolves it and will load the login page.
I’ve seen similar behavior after restarting the Manager backend. The UI sometimes remains blank even after the backend is available again. Waiting for the WebSocket to reconnect or restarting the browser usually resolves it.
Reproduction scenario
This is intermittent, but the following sequence can trigger it:
Open the Manager UI and log in.
Keep the browser tab open and restart the Manager backend.
Reload the UI while the backend is starting or shortly after it becomes available.
Observe that the UI sometimes stays blank instead of loading.
Expected behavior: Once the backend is available, the UI should recover automatically. A temporary connection failure should show a loading or connection status rather than leave a blank screen.
Possible causes
Code inspection suggests several areas to investigate:
Missing WebSocket connection timeout: A connection attempt waits for the browser to report success or failure. If it stalls, subsequent connect() calls reuse the same pending promise rather than start a fresh attempt.
Separate reconnect loops with increasing delays: The event provider and Manager both schedule reconnects, with delays growing to 30 and 45 seconds respectively. This can delay recovery after the backend is available.
UI initialization depends on the initial WebSocket connection: If that connection fails, a later successful reconnect does not rerun app initialization. This could explain why the socket eventually connects but the UI remains blank.
These are potential contributors, not confirmed root causes of the original report. Capturing browser console logs and the /websocket/events connection status during a failure should help distinguish a stalled handshake, retry backoff, and failed UI initialization.
What @wborn describes is intended behavior of the WebSocket reconnect procedure.
The timeout increases over time (which is common across the web), which results in "long wait times" when you disconnect+connect the server.
So it's intended behavior, which we can discuss if it should be changed.
The behavior what @pierrekil is describing is about initial load page time.
If it turns the WebSocket halts the loading process, which is definitely should not, it's worth looking into it.
But I don't expect it to be related to the WebSocket, rather something related to a 404 during initialization.
Activity
wborn commentedon Oct 30, 2026
I’ve seen similar behavior after restarting the Manager backend. The UI sometimes remains blank even after the backend is available again. Waiting for the WebSocket to reconnect or restarting the browser usually resolves it.
Reproduction scenario
This is intermittent, but the following sequence can trigger it:
Expected behavior: Once the backend is available, the UI should recover automatically. A temporary connection failure should show a loading or connection status rather than leave a blank screen.
Possible causes
Code inspection suggests several areas to investigate:
connect()calls reuse the same pending promise rather than start a fresh attempt.These are potential contributors, not confirmed root causes of the original report. Capturing browser console logs and the
/websocket/eventsconnection status during a failure should help distinguish a stalled handshake, retry backoff, and failed UI initialization.MartinaeyNL commentedon Oct 30, 2026
What @wborn describes is intended behavior of the WebSocket reconnect procedure.
The timeout increases over time (which is common across the web), which results in "long wait times" when you disconnect+connect the server.
So it's intended behavior, which we can discuss if it should be changed.
The behavior what @pierrekil is describing is about initial load page time.
If it turns the WebSocket halts the loading process, which is definitely should not, it's worth looking into it.
But I don't expect it to be related to the WebSocket, rather something related to a 404 during initialization.