fix(st-8nn): arm the out-of-band snapshot gate, and key it on content

[dkoosis]

st-8nn filed this as "the server cache self-churns on its own reads, same disease counts had." Investigating it turned up the opposite failure and two more alongside it — the gate has never fired in production at all.

What was actually broken

1. The gate was never armed. publishList — the only publish path a request takes — built its snapshot without reading the store signal. putList stamps it correctly but has no non-test caller. Both freshEntryLocked and checkStale skip an unstamped entry, so strand served a stale board for the life of the process after any bd-CLI or fleet-agent write. Probed directly before fixing: storeAt was zero after a real cachingSource.List.

2. The signal was mtime. That is st-8nn's original point and it stands — a pure bd read rewrites the manifest with byte-identical content. Arming the gate on mtime would have swapped one bug for its mirror image: the server evicting the snapshot it just published, which is the self-churn internal/counts fixed in sd-3wp.1 by moving to a content key. The two changes had to land together.

3. handlePulse never did what its comment says. The doc describes calling checkStale and kicking a background rebuild (st-2fy.5); the body only rendered. checkStale had no production caller.

Fix

• publishList stamps the key on both branches. The unchanged-list branch restamps too — the list was just re-validated against bd, so keeping the old key would make the very next read evict a snapshot just confirmed good.
• bd.StoreContentKey replaces bd.StoreMTime behind the seam. Equality replaces ordering, which also catches a rollback (bd dolt reset) that mtime cannot.
• handlePulse kicks the rebuild after the render, detached from the request ctx like handleHome's deps prefetch.
• storeKeyOK rides alongside the key because 0 is a legal hash value and cannot double as "unset".

Tests

Two of the three tests over this gate passed vacuously. TestSnapshotCacheStoreMTimeGate asserted one spawn after the store moved and explained it as "filesystem signals are not authoritative" — the real cause was that nothing could ever evict. They now assert eviction. New: TestSnapshotCacheStoreKeyStampedOnPublish guards fault 1 directly, and a restamp test covers publishList's unchanged-list branch.

make check green, -race green on internal/server.

Closes st-8nn

[coderabbitai]

Important

• 🔍 Trigger review

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

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e576a1c4-e099-46a4-961f-e4a87fde1498

---

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.}