Version
2026.07.02
Unraid Version
7.3.2
Bug Description
Syslog collects entries like this roughly daily:
Aug 8 09:44:27 Tower compose.manager: [WARN] [dockerload] WebSocket error - Data: {"code":{"isTrusted":true},"desc":{}}
They correlate with a browser tab (Docker page open) waking from laptop sleep or changing networks — i.e., any time the dockerload stats WebSocket drops client-side. The subscriber reconnects automatically and the UI recovers on its own, so there's no functional problem; it's pure log noise.
Two issues in the handler (javascript/composeManagerMain.js, composeDockerLoad.on('error', ...) around line 2778):
-
Severity: a routine, self-healing client-side reconnect gets POSTed to the server and written to syslog at WARN. Since the server-side composeLogger already drops debug-level messages when DEBUG_TO_LOG is off, logging this at debug instead would keep it available for troubleshooting without polluting every user's syslog.
-
Payload: the handler assumes callback args (code, desc), but it receives a DOM Event object. JSON.stringify of an Event yields {"code":{"isTrusted":true},"desc":{}}, which carries no diagnostic information. If details are worth logging, extract fields explicitly (e.g., event type, socket readyState) rather than serializing the raw Event.
Suggested fix
Change the log level in that on('error') handler from 'warn' to 'debug' (verified locally that this silences the syslog noise while DEBUG_TO_LOG="false"), and optionally fix the event serialization so the message is useful when debug logging is enabled.
Expected Behavior
Routine client-side WebSocket disconnects (laptop sleep/wake, network changes) should reconnect silently ithout writing anything to the server syslog at WARN level. Warnings in syslog should be reserved for actionable problems — e.g., the subscriber permanently failing to reconnect. If reconnect events are logged at all, they should be at debug level (gated behind DEBUG_TO_LOG) and include useful details (event type, socket readyState) instead of a serialized DOM Event that renders as {"code":{"isTrusted":true},"desc":{}}.
Steps to Reproduce
- Open the Unraid Docker tab with Compose Manager installed, in a browser on a laptop.
- Sleep the laptop (or switch Wi-Fi networks), then wake it.
- Observe the [WARN] [dockerload] WebSocket error entry in syslog.
Relevant Logs
Compose
Additional Context
No response
Version
2026.07.02
Unraid Version
7.3.2
Bug Description
Syslog collects entries like this roughly daily:
Aug 8 09:44:27 Tower compose.manager: [WARN] [dockerload] WebSocket error - Data: {"code":{"isTrusted":true},"desc":{}}
They correlate with a browser tab (Docker page open) waking from laptop sleep or changing networks — i.e., any time the dockerload stats WebSocket drops client-side. The subscriber reconnects automatically and the UI recovers on its own, so there's no functional problem; it's pure log noise.
Two issues in the handler (javascript/composeManagerMain.js, composeDockerLoad.on('error', ...) around line 2778):
Severity: a routine, self-healing client-side reconnect gets POSTed to the server and written to syslog at WARN. Since the server-side composeLogger already drops debug-level messages when DEBUG_TO_LOG is off, logging this at debug instead would keep it available for troubleshooting without polluting every user's syslog.
Payload: the handler assumes callback args (code, desc), but it receives a DOM Event object. JSON.stringify of an Event yields {"code":{"isTrusted":true},"desc":{}}, which carries no diagnostic information. If details are worth logging, extract fields explicitly (e.g., event type, socket readyState) rather than serializing the raw Event.
Suggested fix
Change the log level in that on('error') handler from 'warn' to 'debug' (verified locally that this silences the syslog noise while DEBUG_TO_LOG="false"), and optionally fix the event serialization so the message is useful when debug logging is enabled.
Expected Behavior
Routine client-side WebSocket disconnects (laptop sleep/wake, network changes) should reconnect silently ithout writing anything to the server syslog at WARN level. Warnings in syslog should be reserved for actionable problems — e.g., the subscriber permanently failing to reconnect. If reconnect events are logged at all, they should be at debug level (gated behind DEBUG_TO_LOG) and include useful details (event type, socket readyState) instead of a serialized DOM Event that renders as {"code":{"isTrusted":true},"desc":{}}.
Steps to Reproduce
Relevant Logs
Compose
Additional Context
No response