fix(repo): "Updated 9d ago" on a repo nothing had touched for 19 days #5586
ccantynzAI Reviewcommented 2d ago
AI Triage
(no summary)
Priority: medium Risk area: mixed
Suggested labels: (no label suggestions) Suggested reviewers: (no reviewer suggestions)
Suggestions only — nothing has been applied. The PR author stays in control.
gluecron[bot]🤖 botAI Reviewcommented 2d ago
AI review unavailable
The platform's AI balance is exhausted, so AI generation is temporarily unavailable. Nothing was lost. You can queue this as a repair for the internal agent from the repository's Health page, or try again once the balance is restored. The PR is otherwise unchanged.
Cross-repo impact
See what breaks downstream if this PR merges.
⮌ Merged
This pull request was merged into main.
c comment · e edit title · m merge · a approve · r request changes · ? shortcuts
ccantynz/Vapronrendered a header its own page contradicted:Ground truth from the bare repo:
Mainat2528cd45committed 2026-08-11, and the newest object write in the entire repository also 2026-08-11 00:01. Nineteen days.The database said
pushed_at = 2026-08-21 17:17— a push that left no objects and no refs. Something bumped the column without the repository changing; a rejected or no-op push is the likely author.Why the existing rule couldn't catch it
reconcileFreshnesstook "whichever is newer". That's correct for the case it was written for — refs written straight to disk bypass the hook, so git being newer must win — and it has no defence against a stored value that was never true. Once a phantom lands in that column, it outranks git permanently.The distinguishing question
The legitimate case (force-push to older history, importing old commits) and the phantom look identical if you only compare dates. But they differ in one cheap, observable way:
A real push writes a ref.
So a stored time may now only outrank git when a ref write corroborates it, within five minutes for clock skew and a slow receive. The force-push case writes refs at push time and still wins — pinned by a test.
newestRefWriteAtlooks only atpacked-refsand the loose files underrefs/— what a push actually touches, and a handful of stats rather than a walk of the object store. A repo with a million objects must not make its own page slow to render.nullmeans "we could not look", never "nothing was written." An unreadable filesystem is our problem and must not silently rewrite a date an operator uses to judge whether a system is alive — precisely the reliance this module's header describes, where the owner once spent a day believing Vapron had stopped receiving pushes.Tests
11, including the literal Vapron numbers. Verified by mutation: removing the corroboration check restores the phantom and fails the suite. The five pre-existing tests pass untouched, because the new argument defaults to "could not look".
What this does and doesn't do
It makes the header honest. It does not make Vapron fresh — that repo genuinely has had nothing pushed since 2026-08-11, because the Vapron agent works against box-158's own Gluecron instance. The page will now say nineteen days, which is the useful thing to know.