io.atcr.hold.stats.daily was handled in the backfill collection list and in
processor.go's dispatch, but missing from isRelevantCollection, which gates
events before ProcessRecord ever sees them. So daily stats records arrived over
the socket and were discarded at the worker, and the trend charts that read them
got nothing live. This is the "present in one list, missing from the other"
shape CLAUDE.md's firehose checklist warns about. Checked the whole class: this
was the only gap. LayerCollection and ImageConfigCollection are absent
deliberately, having no processor handler, and the test now pins that intent.
Note this is currently masked by the relay outage, so fixing the relay alone
would not have restored the charts.
Separately, the README resolution tried "main" and fell back to "master", but
DeriveReadmeURL never fetches: it parses the source URL and interpolates the
branch, returning empty only for an unsupported platform, which is
branch-independent. So if the main call returned empty the master call returned
empty for the same reason, and the fallback could never fire. Removed, with a
comment recording that a branch fallback has to happen at fetch time after a
404. The other two call sites already do exactly that.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PDqoCE1j3njokkZ9b1C5n9
Neither is a correctness problem; both are round trips on hot paths for
timestamps nothing reads at that resolution.
UpdateUserLastSeen ran per Jetstream event for cached users, so once per indexed
record. DeviceStore.UpdateLastUsed ran per /auth/token call, so once per docker
push and pull including each layer's re-auth. Cheap against a local file, a
network round trip each against a remote primary, and the second sat on the
authentication path.
Both are now throttled to once per five minutes per subject. The MAU queries and
the admin views work in hours or days, so nothing loses meaning. The throttle
state is per-process and lost on restart, costing at most one extra write per
subject per boot; only the lease holder runs the consumer, so exactly one process
is doing the first of these at a time.
UpdateLastUsed stamps the throttle before writing rather than after, so a slow or
failing write cannot let every concurrent layer upload through to pile on more of
them.
Verified by disabling the throttle: 50 back-to-back calls then rewrite the
timestamp every time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>