Deadline-heavy repos get a permanently blank OG card and one full traversal per minute after #144

[lukaso-bot]

Found reviewing PR #144 (round 10). Not a defect in that PR's diff — a cost its correctness fix makes permanent for one class of repo, worth fixing in a PR that is about it.

What #144 does

/internal/* refuses to serve any partial and 503s instead. The rationale is right: a partial with firstRelease: null renders as a definite "not yet released", and a partial with a firstRelease carries the gallop hit whose bisect confirmation the deadline cut short. Neither may be pinned into a 24h OG card, and an OG card cannot render the best-effort caveat the result card does.

The cost

gitlab.gnome.org/GNOME/gimp (large tag set, relayed through the single-instance Anubis container) routinely returns partial with a gallop firstRelease. After #144:

1. unfurl → 503 → web-og renders the neutral placeholder at max-age=60
2. 60s later the crawler retries; the recorded partial has just aged past HARD_TTL_PARTIAL (resolve.ts:38 — also 60), so unpinnable forces a recompute
3. another full findRelease out to the 28s hard deadline, another partial, another 503

HARD_TTL_PARTIAL and web-og's placeholder max-age are both 60 seconds, so the two cadences coincide: the "throttled to one traversal per 60s per key" property internal.ts claims is real but buys nothing against a crawler asking once a minute. Net effect for a deadline-heavy repo:

• the OG card never converges — permanently the neutral placeholder
• upstream load for that key goes from ~0 to one full traversal per minute, for as long as the URL is being unfurled, on the shared token and through a max_instances = 1 relay DO

Before #144 the route cached the gallop tag flat for 30 minutes, so the card rendered something.

Sketch of a fix

Serve the gallop-hit shape but have web-og short-cache it rather than long-cache it. The pin duration is web-og's result ? longCache : shortCache; /internal/* could influence it with a response header (e.g. an explicit cache-control or an x-released-partial: 1 web-og keys off). That restores a card with content while keeping it revalidatable, instead of trading a possibly-wrong 24h pin for a permanently blank one.

Adjacent to #151 (the OG card's cache policy for non-terminal answers) — likely the same change. The firstRelease: null shape should keep 503ing regardless; only the gallop-hit shape is in question.

[lukaso-bot]

Merge ordering for this issue, established while draining #144's round-12 review.

#156 is the third step of three, and doing it earlier ships a regression:

1. fix(web): align /internal/* result cache with the public routes (#143) #144 (open) — /internal 503s a partial rather than hand web-og a tag the bisect never confirmed. Safe against the renderer that is deployed today, which long-caches any non-null result for 24h.
2. fix(web-og): cache the OG card by terminality, not by result presence (#151) #158 (open) — web-og stops pinning non-terminal answers: isTerminal() requires firstRelease != null && !partial, so a partial-backed card is served at PENDING_CACHE (300s) instead of LONG_CACHE.
3. Deadline-heavy repos get a permanently blank OG card and one full traversal per minute after #144 #156 (this) — only once fix(web-og): cache the OG card by terminality, not by result presence (#151) #158 is deployed can /internal return the gallop hit with a 200 without it being pinned for a day. That is the one-line change that removes fix(web): align /internal/* result cache with the public routes (#143) #144's placeholder-never-converges cost for deadline-heavy repos (gitlab.gnome.org/GNOME/gimp).

The TTL question #156 has to answer deliberately. PENDING_CACHE is 300s, but HARD_TTL_PARTIAL upstream is 60s — so a 300s partial card outlives the entry behind it 5x. Either #156 picks a partial-specific TTL at or under 60s, or it accepts that a partial card is up to 5 minutes behind the cache. Pick one on purpose; do not inherit 300s by default.

Related: #159 covers the other surfaces that still treat a partial-with-a-firstRelease as terminal (hardTtlFor()/isFresh() at 30 days, badge.ts at 24h). #156 does not depend on it, but they are the same misclassification.

[lukaso-bot]

Sequencing: this should be the next OG-area merge after #144.

#144's round-19 review (thread on internal.ts:359) confirmed the regression this issue exists to close. At head 7da69e4, /internal 503s on every partial; web-og's fetchResult() sees a non-OK response and renderImage() emits PlaceholderCard at max-age=60. HARD_TTL_PARTIAL is also 60 (resolve.ts:38), so for a URL under active unfurling the two cadences coincide, the throttle buys close to nothing, and a repo that reliably blows the soft deadline (GNOME/gimp: large tag set behind the single-instance relay) gets the neutral placeholder permanently — plus one full traversal per minute for as long as the link circulates.

On main that path returned 200 with the gallop partial and the card rendered firstRelease.tag under the 24h longCache. So #144 trades "possibly-wrong tag pinned 24h" for "never converges" — the safe direction, but a real availability regression for exactly the repo class #143 was reported against.

This issue closes the window. Let web-og render the gallop hit with a caveat and short-cache it by terminality, instead of dropping it. Pairs with #160 (ResultCard currently ignores result.partial).

Recommended order: merge #144, then this + #160 before anything else in the OG area. Recorded on #144's thread as well so the human sees the same sequencing from both sides.