Summary

Presence no longer decides whether a device can receive tool calls. It only feeds the dashboard's online dot.

A device is ready when its channel is joined and its mcp_devices row says so (capability, then status = online). Presence is sent once per join, on the side.

Why

On 2026-10-13 Supabase Realtime's PresenceHandler.track/2 hit its 5 s timeout, and that timeout ends the whole channel. Devices then looped: join → track → channel dies → rejoin → track again. Dispatch fell to 12% for ~49 min.

The device made it worse because it treated presence as required:

• no presence → createChannel() rejects, no online write, no heartbeat
• 5 min of presence failures → transport_broadcast_v1 withdrawn, so the server refuses every call
• every rejoin and every 10 s health check published again

Presence is not needed for dispatch. The server never reads it; it dispatches by status and the capability flag. Only the dashboard reads presence.

Presence failures are also not rare. Daily remote_channel_presence_track_error share in BigQuery: 10-05 55%, 10-06 19%, 10-07 32%, 10-08 23%, 10-13 83% (14k–45k devices/day). On normal days it is 0.4–0.65%.

What changes (src/remote-device/remote-channel.ts)

#844's reconnect backoff now resets once the row writes land, not once presence works. What stops the 10-13 loop is the presence wait: a rejoin does not track again until it ends.

Unchanged: the 75 s heartbeat watchdog, capability withdrawal after 3 failed recreates, the offline write on every channel error, and the 5 min heartbeat.

DB writes for a healthy device are the same as before: 2 at join, 1 heartbeat every 5 min.

Compatibility

• Server: no change needed. The device still writes transport_broadcast_v1 and status exactly as the current prod server expects.
• Dashboard: it trusts presence only for broadcast-capable devices. On a bad presence day, a working device can show grey there while tool calls still reach it. Follow-up in remote-dc-mcp: dot = in presence OR (row online and last_seen < ~7 min).
• Overlap: builds on fix(remote): prevent sustained Realtime reconnect stampedes (P1) #844. Covers what fix(remote): keep Presence ACK separate from readiness writes (P1) #843 (draft) does, without a join counter, so fix(remote): keep Presence ACK separate from readiness writes (P1) #843 can be closed once this lands.
• Telemetry: remote_channel_presence_tracked now means presence only; it used to fire only when the device was fully ready. No dashboard or monitor reads it today, but BigQuery queries that used it as "device ready" should split by version.

Tests

New test/test-remote-presence-best-effort.js. These cases check connectivity outcomes only, not wait times:

1. a joined channel is ready for tool calls even when presence fails
2. presence failing never takes a connected device out of service
3. the heartbeat keeps a connected device online while presence fails
4. when presence ends the channel, the rejoined channel stays connected (main drops it 5 times in 2 min)
5. a reconnect while the online write is still running ends with the row online
6. a rejoin whose own online write fails still ends with the row online
7. a drop during the capability write leaves the row offline

Cases 1–4 fail on 67694ca and pass here. Case 5 fails if a rejoin reuses the old join's write. Cases 6–7 came from review and failed on d2ea539.

Six existing remote test files were updated because they asserted the old rule (presence gates readiness) or set the renamed presenceTracked → channelReady field. Presence wait-time tests were removed.

npm test (macOS, Node 26): 172/173. The one failure was test-remote-report.js treating the host name Mac inside macOS as a leak. That is already fixed on main by 38f640a.

Staging test (2026-10-14 at d2ea539, Node 22, packed like npx with realtime-js 2.117.3)

Faults were injected by a test-only preload: presence never answered, presence answer killing the channel, online write refused or held, socket closed. All 10 scenarios passed: pairing with 26/26 tools, presence failing, presence coming back, heartbeat while presence fails, refused online write, a drop during a held write, a socket drop, a 90 s freeze, and Ctrl+C.

10-13 replay, same fault for 17 min:

Re-checked on staging at d1473ad: the new startup hint shows, a refused online write recovers within seconds of the fault ending, and the case-6 race (held write, drop, rejoin's own write refused) recovers by itself in 8 s, where d2ea539 would wait for the next 5 min heartbeat.

Follow-ups (separate PRs)

1. remote-dc-mcp: stop refusing calls on a missing transport_broadcast_v1, one 15 min sweep tier, dashboard dot as above. Ship the dashboard change before or with the release carrying this PR: after a long presence outage the wait is 60–90 min, so the dot would stay grey that long.
2. Device, after that server change is live: stop writing the flag, so a join needs 1 row write and one heartbeat interval.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved remote-device readiness detection so devices can become ready when status updates succeed, even if presence tracking is unavailable.
  • Added more reliable retries and recovery for readiness, heartbeat, reconnect, and pending requests.
  • Prevented unreachable or shutting-down devices from publishing misleading online heartbeats.
  • Improved handling of temporary connection failures, including half-open connections and failed presence updates.

• Documentation

  • Updated readiness messaging to clearly indicate when a device is ready.