Stop the room alarm loop after a rematch lock expires

[Finesssee]

What

An expired rematch lock is now saved away by the tick. Before, expireState removed it in memory without setting changed, so advance never wrote the state. scheduleAlarm then read the stored lock, saw until in the past and called setAlarm(now + 1). The room woke about 8 times a second until some other change got saved.

Evidence (production observability, last 7 days)

• 163,910 alarm invocations on the prod Worker, against about 7,900 page/API requests.
• 138,460 of them in one channel room. Events show back-to-back alarms about 120 ms apart for minutes at a time after duels, e.g. 2026-10-15 15:43, 16:04 and 18:08 to 18:17 UTC.
• Daily alarm counts ranged from 4,070 to 42,671. Durable Object requests on the Free plan are capped at 100,000 a day, so a busy stream day could hit it.

Change

• server/game.ts: mark the state changed when the lock filter drops a lock.
• tests/channel.test.ts: a stored expired lock is gone after alarm() and no alarm is due right away (red before the fix).
• docs/CONTRACTS.md: one line on the tick saving every expiry.

bun run check passes (401 tests).

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: nesszer/pixfray/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 22b20404-6be2-45ba-8bfb-b3374bf03d42

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}