partial-with-a-firstRelease is cached as terminal on the web + badge surfaces (30d / 24h), so a truncated traversal pins a possibly-wrong tag

[lukaso-bot]

hardTtlFor() and badge.ts treat a soft-deadline partial that carries a firstRelease as terminal, so a truncated traversal's answer is pinned: 30 days in the result cache, 24h at camo.

packages/web/src/resolve.ts:54:

function hardTtlFor(r: LookupResult): number {
  if (r.firstRelease) return HARD_TTL_RELEASED; // 30 days
  if (r.partial) return HARD_TTL_PARTIAL;
  return HARD_TTL_PENDING;
}

isFresh() (same file, :60) has the same ordering — if (entry.value.firstRelease) return true — so such an entry never revalidates. packages/web/src/routes/badge.ts:141 does the same thing at the edge: resolved.result.firstRelease ? LONG_CACHE : SHORT_CACHE, and badgeStateForResult renders the tag rather than checking… whenever firstRelease is set.

Why it matters. A partial means the traversal was truncated by the soft deadline, so its firstRelease is a best-effort answer, not confirmed to be the earliest release containing the commit. Concretely: the gallop finds v2.0.0 and the deadline blows before it can walk back to v1.9.0, which is the true first release. That wrong-but-plausible tag is then treated as final — kept for 30 days in the result cache and served to camo with a 24h TTL — with no path to correction short of the cache entry expiring.

Deadline-heavy repos (gitlab.gnome.org/GNOME/gimp, kubernetes/kubernetes) are exactly where partial is common, so this is not a rare edge.

Where it came from. Found while reviewing #158 (fix(web-og): cache the OG card by terminality, not by result presence). #158 fixes the OG surface — its isTerminal() requires firstRelease != null && !partial, so an OG card for a partial revalidates every 300s. That makes #158's OG lifetime stricter than the web/badge surfaces, and this issue is the remaining half: #151 asked for "cache by whether the answer can still change", and on the result cache + badge it still caches by "did an answer come back".

Sketch of the fix. Test partial before firstRelease in both hardTtlFor() and isFresh(), so a partial-with-release gets HARD_TTL_PARTIAL and revalidates; and key badge's cache lifetime on firstRelease && !partial to match. Needs a deliberate call on the badge copy: a partial-with-release should probably still render the tag it found (better than checking…) but with the short TTL, so it self-corrects.

Not fixed in #158 — that PR touches only packages/web-og, and this is packages/web. Filed separately so the change lands in a PR that is about it.

[lukaso-bot]

Reachability escalation + the two exact lines, from #144 review round 16.

Verified against the code rather than restated:

• resolve.ts hardTtlFor() tests if (r.firstRelease) return HARD_TTL_RELEASED before it tests r.partial. A gallop shape — firstRelease set and partial: 'soft_deadline' — therefore takes the 30-day terminal branch.
• resolve.ts isFresh() does the same: if (entry.value.firstRelease) return true, with no age bound at all. So once written, that entry is fresh forever and is never revalidated.

Consequence on the public surfaces, which read the slot directly rather than through shouldRecompute: badge.ts renders the unconfirmed tag as a definite release with the 24h long-cache and no caveat (a badge has nowhere to put one), and the permalink serves it from cache without ever recomputing.

What changed with #144: aligning the /internal cache key makes that endpoint a writer of the same slot the public routes read. Before, only a human page view or a badge fetch could install this shape; now an unauthenticated crawler unfurl can, and each further unfurl rewrites the entry and restarts the 30-day clock, so it cannot age out while the link circulates. The defect is unchanged and pre-existing — #144 does not introduce it — but the exposure widens from human traffic to crawler traffic, which is worth weighing when ranking this.

Fix direction is unchanged and belongs here rather than in #144, because it changes the cache policy for every reader of the slot: hardTtlFor and isFresh should both branch on terminality (firstRelease && !partial), not on firstRelease alone.

[lukaso-bot]

Priority up — #144's review found a widening of the trigger surface (round 19, thread on internal.ts:239).

Re-verified at 7da69e4:

• resolve.ts:74-78 — hardTtlFor() tests r.firstRelease before r.partial, so a gallop partial (firstRelease set and partial set) is written at HARD_TTL_RELEASED = 30 days.
• resolve.ts:80-84 — isFresh() returns true unconditionally on firstRelease, before the partial arm, so it is never revalidated.
• badge.ts badgeStateForResult() orders the same way, so the README badge renders that tag under LONG_CACHE (86400s) with no caveat.

The bisect that would confirm no earlier release contains the commit is exactly what the soft deadline cut short, so the pinned tag can name a later release than the true first one.

What #144 changes: not the misclassification — that is identical on main, where a human page view or a badge fetch writes the same 30-day entry into the same 5-part slot. What changes is who can be the first writer: after #144, /internal shares that key, so an unauthenticated OG unfurl can pin it without anyone visiting the page. Bounded (an unfurl means the link was just posted somewhere people are about to click), but it removes the human-in-the-loop precondition.

Fix shape — hardTtlFor() must test partial before firstRelease, and isFresh() likewise. Both are one-line reorderings, but they change PUBLIC-route behaviour: a gallop partial drops from 30d to 60s for every caller, so a large-tag-set repo pays a fresh full traversal every minute on the human path. That trade needs its own PR, its own tests, and a decision about whether the partial TTL should be raised from 60s at the same time. Deliberately NOT bundled into #144.