From c87f86f82e1b3c1e84d5ec6bc7e45ac340015d9f Mon Sep 17 00:00:00 2001
From: Klesti Selimaj <klesti.selimay@icloud.com>
Date: Wed, 9 Sep 2026 03:03:51 +0200
Subject: [PATCH] Send a ping every 20s to keep the WS connection (and MV3
 worker) alive
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Backend now replies with {"type":"pong"}. See backend commit for the full
rationale: a MV3 background service worker can be idle-killed after ~30s
with no activity reaching its own message handlers, and a disconnect while
a lockout is active used to reset the visible lock state on reconnect
(fixed backend-side) — this keepalive addresses the other half by making
that disconnect much less likely to happen in the first place.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013qK4zsF5ogU7cjRVL3AQZ2
---
 src/background/ws-client.ts | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/background/ws-client.ts b/src/background/ws-client.ts
index 5443108..988ec71 100644
--- a/src/background/ws-client.ts
+++ b/src/background/ws-client.ts
@@ -32,7 +32,22 @@ interface WireError {
   message: string;
 }
 
-type WireMessage = WireLockState | WireAck | WireError;
+interface WirePong {
+  type: 'pong';
+}
+
+type WireMessage = WireLockState | WireAck | WireError | WirePong;
+
+// JSON-level ping, per the protocol's "ping (optional fallback)" section —
+// used here specifically (not relying on the browser's native WS ping/pong
+// alone) because this client runs in a MV3 background service worker, which
+// Chromium can idle-kill after ~30s with no activity reaching its own
+// onMessage-style handlers; a plain protocol-level ping/pong frame isn't
+// guaranteed to count as that activity, but a JSON message our own
+// 'message' listener below processes is. Sending well under that 30s
+// budget (not waiting until the deadline) keeps the socket (and the
+// worker) alive continuously rather than trying to time a wakeup.
+const PING_INTERVAL_MS = 20_000;
 
 const WIRE_TO_INTERNAL_SCOPE: Record<WireScope, LockScope> = {
   buy_only: 'buy-only',
@@ -95,10 +110,14 @@ export function connectWsClient(options: WsClientOptions): WsClientController {
     const socket = new WebSocket(`${BACKEND_WS_URL}?token=${encodeURIComponent(token)}`);
     currentSocket = socket;
     let authFailure = false;
+    let pingTimer: ReturnType<typeof setInterval> | undefined;
 
     socket.addEventListener('open', () => {
       reconnectAttempt = 0;
       options.onStatusChange('connected');
+      pingTimer = setInterval(() => {
+        if (socket.readyState === WebSocket.OPEN) socket.send(JSON.stringify({ type: 'ping' }));
+      }, PING_INTERVAL_MS);
     });
 
     socket.addEventListener('message', (event) => {
@@ -129,9 +148,12 @@ export function connectWsClient(options: WsClientOptions): WsClientController {
       // 'ack' has nothing to react to yet — the client doesn't send
       // unlock_request/escalate_request until lock-decision logic exists
       // server-side (see backend/CLAUDE.md non-goals for this milestone).
+      // 'pong' likewise needs no handling — sending the ping is the whole
+      // point (see PING_INTERVAL_MS above), receiving a reply isn't acted on.
     });
 
     socket.addEventListener('close', (event) => {
+      if (pingTimer) clearInterval(pingTimer);
       if (currentSocket === socket) currentSocket = undefined;
 
       if (manuallyDisconnected) {