Requesting a release that includes the ws keep-alive (d0d0b3f): lone readers reconnect-loop every ~33s on every released version #73

Requesting a release that includes the ws keep-alive (d0d0b3f): lone readers reconnect-loop every ~33s on every released version

We (La Suite Docs / suitenumerique/docs, DINUM — production deployment of @y/hub@0.9.0) are hitting in production exactly the failure mode that commit d0d0b3f ("keep ws clients alive even if they disabled awareness") fixes. The fix is on main since 2026-10-07 but no release contains it (latest is 0.9.1, 2026-09-30), so we cannot pick it up with our registry-pinned install. This issue documents the production evidence and an end-to-end validation of the fix, and asks for a release.

Production symptom

A signed-out visitor opening a public document in reader mode stays connected ~30s, is disconnected, reconnects, and loops like that forever. Grafana/Loki over one hour on our cluster:

• ~10k client connected / ~10k client connection closed per replica per hour, with the whole fleet sitting at a few hundred steady-state connections — most connections live ≈30s.
• Close codes: 1005 ("no status received") 26.3k/h — the dominant code, the signature of a client-side close that sends no status — plus 1006 1.8k/h and 1001 2.2k/h. Only 65 closes of 4401 (genuine revocations).
• Each cycle costs the Docs backend a fresh auth roundtrip per connection: a steady stream of GET /users/me/ 401 (anonymous re-auth) and GET /documents/{id}/ 200 from the yhub pods, plus a full resync of the document every cycle.

Root cause (same mechanism as #55, different trigger)

y-websocket closes and reconnects a socket that received no message for 30s (messageReconnectTimeout, hard-coded in 3.x; socketTimeout, 45s by default in 4.x). WS pings don't count (they never reach client code). Usually other clients' presence renewals feed the watchdog; on our deployment:

• readers are deliberately denied awareness publishing (awareness: '-r--', our fix for 🔒️(yprovider) readOnly connections awareness propagation suitenumerique/docs#2544 — a read-only connection must not propagate cursors), so their own awareness messages are dropped and never echoed back;
• the client's resyncInterval lifeline (SyncStep1 every 20s) is a no-op against yhub, which ignores client SyncStep1 by design ("can be safely ignored because we send the full initial state at the beginning") — so the comment in our frontend claiming it "guarantees inbound traffic" was wrong all along;
• a reader alone on a quiet document therefore receives nothing after the initial sync, and the watchdog fires at 30s (+ check granularity ⇒ ~33s observed), client-side, with close code 1005.

Any sole reader loops — anonymous visitors on public docs are just the guaranteed-to-be-lonely case. This is #55's mechanism with zero inbound traffic instead of one giant message in flight.

End-to-end validation of d0d0b3f

Repro harness: a lone read-only client using the exact stack of our frontend — y-websocket@3.1.0, { disableBc: true, maxBackoffTime: 30000, resyncInterval: 20000 } — against a yhub built from current main granting ydoc: '-r--', awareness: '-r--', ws: '-r--', with no writes for the whole run. Two servers, one difference:

Your testKeepAlive passes, and the full suite is green on main: 171/171 tests (tests/index.js, exit 0).

Ask

A release (0.9.2 or 0.10.0) containing d0d0b3f — either standalone or with whatever else is queued for the next version. Until then our options are an unofficial fork or patch-package over the registry tarball, which we would much rather avoid. Happy to provide additional Grafana panels or the repro script if useful.