[alukach]

Follow-up to #257. That PR made storage the only record of a pending tick alarm, re-arming when getAlarm() returns null. This covers the other way the alarm can be stuck: storage still holds an alarm, but it is long past due and never fires. Then getAlarm() stays non-null, ensureAlarm never re-arms, and the globe stays silent even after a restart clears in-memory state.

The evidence for that case: on 2026-10-20 production was rolled back to b0af0f99 and forward to 912faa3f about 40 seconds apart, and Durable Object analytics show no alarm invocation since (as of 17:10 UTC); a fresh wss://logs.source.coop/ws still receives nothing. No invocation was recorded on b0af0f99 and the open WebSockets weren't dropped, so the object may simply never have restarted — which is why this is a guard rather than a confirmed diagnosis.

ensureAlarm now treats an alarm more than ten emit intervals (5s at the production EMIT_INTERVAL_MS) overdue as dead and overwrites it with setAlarm. A healthy alarm is never more than one interval out, so the guard costs nothing in normal operation.

Shipping this in the same release as #257 means one release resolves production whichever way the alarm is stuck.

Testing

• tsc --noEmit passes; node --test src/aggregate.test.mjs passes 3/3; the pre-push hook's Rust suite passes.
• Not reproducible locally. After the release: open wss://logs.source.coop/ws and expect tick frames within a second, and confirm alarm invocations resume in the Durable Object analytics for public-log-stream.

No ADR covers the log stream's internals; nothing to update in adrs/.

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 16s —— View job

---

✅ No blocking issues — safe to merge.

I read ensureAlarm in workers/public-log-stream/src/location-hub.ts:90 and its two callers (handleWebSocket and handleLocation). I didn't run anything.

• Correctness: The guard is sound. getAlarm() returns null or a future or recent timestamp for a healthy alarm. A healthy alarm is never more than one interval overdue, so the 10× threshold won't misfire.
• Overwriting a live alarm: Calling setAlarm over an existing alarm replaces it. It doesn't stack a second alarm, so two tick loops can't run.
• Alarm retries: If alarm() throws, the runtime retries it with backoff. A retry-pending alarm could be replaced once it is more than 10 intervals overdue. That is harmless, because the replacement just resumes ticking.
• Cost: Each ensureAlarm call already did a getAlarm() read, so the extra comparison adds nothing measurable.
• Not verified: As the PR says, this is a guard and not a confirmed diagnosis. If the alarm is still silent after the release, the cause is elsewhere. The post-release check you describe (tick frames on the WebSocket and alarm invocations in the Durable Object analytics) is the right way to confirm.

Simplify (ponytail)

• None. The change is one condition, with no new abstractions.

---

💰 Estimated review cost: $0.10 · 0m16s · 5 turns

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-260.source-coop.workers.dev

• Date: 2026-10-20T17:17:37Z
• Commit: c874f16