Found while verifying #716. Not a regression from any single change — it is what two key templates that cannot see each other produce.
The evidence
oaklib-Linux-2026-09 3,083,112,678 bytes <- validate-strict's key
oaklib-Linux-2026-08 3,083,112,653 bytes
oaklib-Linux-v1-2026-09 196 bytes <- claw's key, EMPTY
oaklib-Linux-v1-2026-09 197 bytes
From the label-correspondence run log:
key: oaklib-Linux-v1-2026-09
restore-keys: oaklib-Linux-v1-
Cache hit for: oaklib-Linux-v1-2026-09
Cache restored successfully (0.1 s — because it is 196 bytes)
Consequence, in the same run: no already-downloaded builds found, unreachable ontologies: CHEBI, ENVO, GO, NCBITaxon, UBERON, and Wrote 6300 flagged pairs to the drift report.
Meanwhile validate-strict in the same PR restores 3.08 GB and runs the taxonomy gates for real — 2866 passed, 84 skipped.
Why they cannot share
| lane |
key |
restore-key |
validate-strict (this repo) |
oaklib-{os}-{month} |
oaklib-{os}- |
label-correspondence (claw reusable) |
oaklib-{os}-{bust}-{month} |
oaklib-{os}-{bust}- |
Restore-keys match by prefix. oaklib-Linux-v1- matches neither oaklib-Linux-2026-09 nor the original 6.7 GB oaklib-Linux-v1 — the trailing hyphen excludes exactly the entry it looks closest to.
This repo's scheme did carry the data forward: oaklib-Linux- matched the old oaklib-Linux-v1, which is how 6.7 GB became oaklib-Linux-2026-08 and then -09. Claw's scheme started cold, and — because 403 means nothing downloads — saved 196 bytes, which is now pinned for September.
No value of claw's oak-cache-key input fixes this: the template always appends a hyphen, so no bust produces a prefix reaching oaklib-Linux-….
Options
- Align this repo's
validate-strict key to claw's template. Correct long-term, but it would immediately break the working lane: the primary key would hit the 196-byte entry, and a hit means no save. Only viable after the empties are gone.
- Delete the two 196-byte entries (
gh api -X DELETE .../actions/caches?key=...), then either lane can repopulate. Cheap and safe — they hold nothing — but it is a mutation on shared CI infrastructure, so it wants a human's yes. Note GitHub also evicts caches unused for 7 days, so this resolves itself if nothing keeps touching them.
- Upstream: let claw's restore-keys include a broader fallback. Its comment argues against exactly that — a broader
oaklib-{os}- would defeat the manual bust, since a bumped key would match the entry it was bumped to escape. That reasoning is sound, which is why this is filed rather than patched.
Not doing any of them here. Option 2 is the immediate unblock and is one command; I have not run it because deleting cache entries is the user's infrastructure to change.
What is not wrong
The gate is honest throughout: the enforce steps print SKIPPED, NOT PASSED rather than passing, and the drift report is non-blocking. And #716's fix is independently verified — pointed at builds that exist, Engine B checks 6288 pairs and exits 0. It is only the cache that is empty in that one lane.
Found while verifying #716. Not a regression from any single change — it is what two key templates that cannot see each other produce.
The evidence
From the
label-correspondencerun log:Consequence, in the same run:
no already-downloaded builds found,unreachable ontologies: CHEBI, ENVO, GO, NCBITaxon, UBERON, andWrote 6300 flagged pairsto the drift report.Meanwhile
validate-strictin the same PR restores 3.08 GB and runs the taxonomy gates for real — 2866 passed, 84 skipped.Why they cannot share
validate-strict(this repo)oaklib-{os}-{month}oaklib-{os}-label-correspondence(claw reusable)oaklib-{os}-{bust}-{month}oaklib-{os}-{bust}-Restore-keys match by prefix.
oaklib-Linux-v1-matches neitheroaklib-Linux-2026-09nor the original 6.7 GBoaklib-Linux-v1— the trailing hyphen excludes exactly the entry it looks closest to.This repo's scheme did carry the data forward:
oaklib-Linux-matched the oldoaklib-Linux-v1, which is how 6.7 GB becameoaklib-Linux-2026-08and then-09. Claw's scheme started cold, and — because 403 means nothing downloads — saved 196 bytes, which is now pinned for September.No value of claw's
oak-cache-keyinput fixes this: the template always appends a hyphen, so no bust produces a prefix reachingoaklib-Linux-….Options
validate-strictkey to claw's template. Correct long-term, but it would immediately break the working lane: the primary key would hit the 196-byte entry, and a hit means no save. Only viable after the empties are gone.gh api -X DELETE .../actions/caches?key=...), then either lane can repopulate. Cheap and safe — they hold nothing — but it is a mutation on shared CI infrastructure, so it wants a human's yes. Note GitHub also evicts caches unused for 7 days, so this resolves itself if nothing keeps touching them.oaklib-{os}-would defeat the manual bust, since a bumped key would match the entry it was bumped to escape. That reasoning is sound, which is why this is filed rather than patched.Not doing any of them here. Option 2 is the immediate unblock and is one command; I have not run it because deleting cache entries is the user's infrastructure to change.
What is not wrong
The gate is honest throughout: the enforce steps print
SKIPPED, NOT PASSEDrather than passing, and the drift report is non-blocking. And #716's fix is independently verified — pointed at builds that exist, Engine B checks 6288 pairs and exits 0. It is only the cache that is empty in that one lane.