Repository navigation
lint: the public-baseline freshness gate has been failing for 40+ commits, making every later lint step unreachable #7257
Description
lint is a required status check and has been red on main for weeks. The most common cause is step 3, "Public benchmark evidence freshness":
public baseline error: public artifact benchmark inputs changed; regenerate it with ./benchmarks/run_public_baseline.sh
##[error]Process completed with exit code 2.
Seen in nightly runs 30735945650 (08-02) and 30519299737 (07-30); 30687607155 (08-01) and 30610234977 (07-31) failed one step earlier on workspace_architecture, which has since been fixed.
Why this is the urgent one
The steps in the lint job run in order and the job stops at the first failure. This step is #3 of 10, so while it is red, every later gate is unreachable and therefore inert:
| # | step | status at cdb3934 |
|---|---|---|
| 1 | cargo fmt --all -- --check |
PASS |
| 2 | workspace_architecture.py --check |
PASS |
| 3 | ci_public_baseline_check.py |
FAIL (2) |
| 4 | check_file_size.sh |
FAIL (fixed by #7256) |
| 5 | binding_pins.mjs --check |
PASS |
| 6 | gc_store_site_inventory.py |
FAIL |
| 7 | addr_class_inventory.py |
FAIL |
| 8 | gap_snapshot.py --self-test |
PASS |
| 9 | parity_known_failures.py --self-test |
PASS |
| 10 | gc_gate_wiring_check.py |
PASS |
This is CLAUDE.md's hazard (2) in its most expensive form: a required job that is always red blocks nothing, because every merge bypasses it with --admin. Notably #7253 wired the new gc_gate_wiring_check.py into step 10 — a correctly-built gate that cannot currently fail a merge, because the job never reaches it.
Diagnosis
Both fingerprints are stale, not just one:
recorded source_fingerprint : 9713a2e1131dbc407e2f6e7b056b9e2e1092ed45be7ecd5bf88b3d5a9910405f
computed source_fingerprint : ca3101d49a02fdd17c3955c9d26d87206fe2d9e063ee5978b62181d59d5885d5
recorded harness_fingerprint: 437f64a8020aebd4d677405b4e5c8d915b2c76b10977df397ed324eef7b3ae23
computed harness_fingerprint: 8c6d17228131f215878846a970d7f97156bb9e8de73bdbee5537ee055b389aaf
benchmarks/results/public-node-bun-v1.json records generated_at: 2026-07-13T14:10:04Z / perry 0.5.1258. Recomputing tracked_fingerprint(SOURCE_PATHS) and tracked_fingerprint(HARNESS_PATHS) at each of the last 40 commits on main shows both have been stale for every one of them — this is not a single recent regression.
MAX_AGE_DAYS = 45 is not the problem (the artifact is ~20 days old); it is validate_public's fingerprint equality checks at benchmarks/public_baseline.py:520 and :524.
The last commit to touch the artifact is 7beb3a5 (#7165, 08-01, "scrub committed home-directory paths, stop the harnesses re-emitting them"). That PR edited harness files under HARNESS_PATHS and the artifact, but the recorded fingerprints do not match the tree at any point since.
Why it can't be fixed by hand
This is by design — harness_fingerprint changing means "the measurement apparatus changed, so the numbers are not comparable". Clearing it requires actually regenerating the artifact:
./benchmarks/run_public_baseline.sh
which needs the pinned Node v22.23.1 + Bun 1.3.14, a dist-profile Perry, the quiet-CPU gates, and the documented host. Editing the JSON to paste in new hashes would defeat the gate's entire purpose.
Suggested resolution
- Regenerate the artifact on the pinned host and land it.
- Consider whether
SOURCE_PATHSincluding the rootCargo.tomlis too broad — it already special-cases theversionfield (fix(bench): version-invariant Cargo.toml fingerprint in the public-baseline gate #6528), but any dependency bump also invalidates it and forces a full benchmark re-run to keeplintgreen. That coupling is why this goes stale so easily. - Once green, verify that steps 4–10 actually execute, and re-check that
gc_gate_wiring_check.pycan fail.
Activity
proggeramlug commentedon Aug 2, 2026
Confirmed still open on
main=d4ac65f21. Re-verified in the sweep #7262.Byte-identical to the reported failure, now also at
d4ac65f21(this issue measuredcdb393434), so #7256 did not change it either way.Confirming the downstream claim as well, since it is the reason this is the urgent one: steps 6 and 7 of
lintboth fail independently when run directly —scripts/gc_store_site_inventory.py→ exit 1 (lint: gc_store_site_inventory has 19 unaudited store sites on main #7258)scripts/addr_class_inventory.py→ exit 1 (lint: addr_class_inventory fails on main — 2 real ratchet regressions plus a stale allowlist substring #7259)— and neither has been visible in CI because the job stops here at step 3. Step 10's
gc_gate_wiring_check.py, wired in by #7253 specifically to make the moving-GC gate wiring assertable, is likewise unreachable. That is a correctly-built gate that cannot fail a merge, which is the exact failure mode #7253 was written to fix.fix(bench): regenerate the public Node/Bun baseline, and register the…