WebSocket disconnects from zmeventserver after app is backgrounded and resumed

[kunickig]

zmNinjaNg version and build number

2.0.0

Platform

Android

OS / browser version

Android 16

Device

No response

ZoneMinder version

1.39.17

Event Server (ES) version

nevest

zm_detect version

nevest

Describe the bug

Every time I background the app for a while and then reopen it, the connection to zmeventserver shows as disconnected, with "Failed to connect to notification server" and "WebSocket error" in the logs (isTrusted: true, no further detail). Tapping "Connect" manually reconnects instantly — it's not a real connectivity issue, the app just doesn't automatically re-establish the WebSocket after coming back from background.
Interestingly, push notifications still arrive normally even while the app shows this WebSocket as disconnected — so the disconnect seems limited to the in-app WebSocket state and doesn't affect the actual push notification delivery. This suggests the WebSocket reconnect logic on resume is broken/not triggered, separate from whatever channel delivers the push notifications.

Steps to reproduce

Open the app, confirm notification server is connected.
Background the app (or lock the phone) for a few minutes.
Reopen the app.
Notification server shows disconnected with the errors above.
Tap "Connect" — reconnects immediately.

Expected behavior

App should automatically reconnect the WebSocket when resumed from background, or at least retry silently instead of requiring a manual tap. The UI state should also more accurately reflect what's actually working, since push notifications keep working despite the "disconnected" status.

Screenshots / logs

Additional context

No response

[pliablepixels]

Claude here, assisting @pliablepixels.

Traced this. It is not Android-specific, though Android reproduces it most often. Three separate dead ends in shared code, fixed in PR #276:

1. A socket that outlives an app suspension still reports readyState === OPEN, so the app state stays connected. The liveness check on resume detected the dead connection and called reconnectNow(), which declines while the state says connected. The one caller that knew the connection was dead was the one caller refused.
2. When the socket had already closed, the resume handler returned early and left recovery to a backoff timer that the suspended WebView had frozen, up to its two-minute cap.
3. The 20-second auth timeout cleared the socket reference before closing it, so the close event was ignored by the handler guard and no reconnect was ever scheduled. That path stranded the service in the error state until a manual Connect, which matches the log you posted.

Resume now reconnects immediately when the connection is not live, and every failure path ends in either a live socket or a scheduled retry.

Your other observation is expected behavior: push notifications travel over FCM, a separate channel from the in-app WebSocket, so they keep arriving while the socket is down. The badge is reporting the WebSocket accurately.

The fix has unit coverage, but Android and iOS resume are manual checks here, so a confirmation from your device after the next build would be useful.

[pliablepixels]

@kunickig can you give this a test? https://drive.google.com/file/d/1n5k7t-H90OXyWMI8Adz3s22oOYQ7spix/view?usp=drive_link

[kunickig]

Of course, I'll test it and let you know if it works. I'll just add that my antivirus thinks it's a malicious file...

[kunickig]

Unfortunately, it's still the same. It disconnects and I have to click connect manually. The logs are the same. But wait, I'll test it longer, because we have the impression that it happens less often than before

[kunickig]

unfortunately the same thing is still happening.

[pliablepixels]

Hmm, I wonder if I sent you a build w/o it...
I am not seeing that in my logs. The only diff is I am not using SSL in my home setup. Let me post with a new build

First connect
07/25/2026 05:19:07.187782 zmeventnotification[2214738].DB1 [main:795] [got a websocket connection from 192.168.50.4 (4) active connections]
07/25/2026 05:19:07.192902 zmeventnotification[2214738].DB1 [main:840] [Websockets: New Connection Handshake requested from 192.168.50.4:52892 state=pending auth, id=1784971147.19284]
07/25/2026 05:19:07.226130 zmeventnotification[2214738].DB1 [main:795] [got a websocket connection from 192.168.50.4 (5) active connections]
07/25/2026 05:19:07.230120 zmeventnotification[2214738].DB1 [main:840] [Websockets: New Connection Handshake requested from 192.168.50.4:51372 state=pending auth, id=1784971147.23006]
07/25/2026 05:19:07.254653 zmeventnotification[2214738].INF [ZmEventNotification::WebSocketHandler:548] [Correct authentication provided by 192.168.50.4]

Move to background 
07/25/2026 05:19:20.904192 zmeventnotification[2214738].DB1 [main:852] [Websocket remotely disconnected from 192.168.50.4]
07/25/2026 05:19:20.904438 zmeventnotification[2214738].DB1 [main:865] [Marking 192.168.50.4 for deletion as websocket closed remotely]
07/25/2026 05:19:21.419353 zmeventnotification[2214738].DB1 [main:852] [Websocket remotely disconnected from 192.168.50.4]
07/25/2026 05:19:21.419532 zmeventnotification[2214738].DB1 [main:865] [Marking 192.168.50.4 for deletion as websocket closed remotely]

Resume from background:
07/25/2026 05:20:40.600931 zmeventnotification[2214738].DB1 [main:795] [got a websocket connection from 192.168.50.4 (4) active connections]
07/25/2026 05:20:40.601789 zmeventnotification[2214738].DB1 [main:840] [Websockets: New Connection Handshake requested from 192.168.50.4:39570 state=pending auth, id=1784971240.60174]
07/25/2026 05:20:40.721611 zmeventnotification[2214738].INF [ZmEventNotification::WebSocketHandler:548] [Correct authentication provided by 192.168.50.4]


Kill:
07/25/2026 05:20:58.803570 zmeventnotification[2214738].DB1 [main:852] [Websocket remotely disconnected from 192.168.50.4]
07/25/2026 05:20:58.803749 zmeventnotification[2214738].DB1 [main:865] [Marking 192.168.50.4 for deletion as websocket closed remotely]


Start:
07/25/2026 05:21:18.111658 zmeventnotification[2214738].DB1 [main:795] [got a websocket connection from 192.168.50.4 (4) active connections]
07/25/2026 05:21:18.112313 zmeventnotification[2214738].DB1 [main:840] [Websockets: New Connection Handshake requested from 192.168.50.4:50382 state=pending auth, id=1784971278.11227]
07/25/2026 05:21:18.135944 zmeventnotification[2214738].INF [ZmEventNotification::WebSocketHandler:548] [Correct authentication provided by 192.168.50.4]
07/25/2026 05:21:18.156216 zmeventnotification[2214738].DB1 [ZmEventNotification::WebSocketHandler:352] [JOB: Duplicate token found: marking ...Pi5EUM5kY8 to be deleted]
07/25/2026 05:21:18.156375 zmeventnotification[2214738].DB1 [ZmEventNotification::WebSocketHandler:411] [JOB: Storing token ...Pi5EUM5kY8,monlist:,intlist:,pushstate:enabled]

[pliablepixels]

Let's try this again @kunickig - link

It would be useful if you could post ES logs when this is going on like above

[kunickig]

With this version, I haven't had a single disconnection so far. However, errors still appear in the logs occasionally. Even though it's constantly connected, errors sometimes appear.

[pliablepixels]

Sounds good - yes, errors can happen on sudden disconnects but glad it recovers quickly. I'll close this tomorrow so you get some soak time to validate.