Observed during post-deploy verification of d9106a0, on the live origin.
What happened
Sent a document with choices and a GFM table to a freshly minted code:
send_to_reader 8427X → {"version":1,"delivered":true,...}
GET /s/8427X?v=0&p=1&n=1 → 200 {v:1, title:"Post-deploy check", table rendered}
GET /s/8427X?v=1 → 204 (correct: no change)
~25 minutes later, with no writes and no taps in between:
GET /s/8427X?v=0 → 204
check_reader → {connected:true, version:null, title:null}
version:null means the DO's storage no longer holds v — the document is gone, while the DO itself is alive and tracking polls.
What it isn't
- Not the 6h TTL.
putDoc arms the alarm at now + TTL_MS; alarm() re-arms unless idle >= TTL_MS. 25 minutes is nowhere near it.
- Not a general regression. A clean control session (
3TZF8, same deploy) held its document correctly across 60s of polling — v=0→200 / v=1→204 on every probe.
- Not rate limiting. Well under
RL_ALL (240/60), and a throttle returns 429, not an empty session.
Deltas between the two sessions
8427X had, and 3TZF8 did not: choices passed on the send; a GFM table in the body; its /<code> reader page fetched; and p/n reading-position params on the poll (state.read written).
Next step
Unreproduced — the failure took ~25min to surface, longer than the verification window. Worth a patient repro: send with choices + p/n heartbeat, then poll every few minutes for an hour, and watch whether alarm() fires early. If it reproduces, instrument alarm() with the computed idle before the deleteAll branch.
Filed rather than left in a terminal.
Observed during post-deploy verification of
d9106a0, on the live origin.What happened
Sent a document with
choicesand a GFM table to a freshly minted code:~25 minutes later, with no writes and no taps in between:
version:nullmeans the DO's storage no longer holdsv— the document is gone, while the DO itself is alive and tracking polls.What it isn't
putDocarms the alarm atnow + TTL_MS;alarm()re-arms unlessidle >= TTL_MS. 25 minutes is nowhere near it.3TZF8, same deploy) held its document correctly across 60s of polling —v=0→200 /v=1→204 on every probe.RL_ALL(240/60), and a throttle returns 429, not an empty session.Deltas between the two sessions
8427Xhad, and3TZF8did not:choicespassed on the send; a GFM table in the body; its/<code>reader page fetched; andp/nreading-position params on the poll (state.readwritten).Next step
Unreproduced — the failure took ~25min to surface, longer than the verification window. Worth a patient repro: send with
choices+p/nheartbeat, then poll every few minutes for an hour, and watch whetheralarm()fires early. If it reproduces, instrumentalarm()with the computedidlebefore thedeleteAllbranch.Filed rather than left in a terminal.