[squid-protocol]

Part of #4863 (step 6: a fast Db2 job).

Why. The Db2 job is the refresh's critical path. On the 10/10 nightly (run 38043242484) it took 34 min, against at most 16 for every other job. 25.5 min of that is the sweep: 38 cases / 673 scenarios at --jobs 4 on one 4-vCPU runner that also hosts Db2, about 9 s per scenario per slot (mostly the fixed cost of each Db2 CLP call and JVM start). After the sweep, it re-proves 4 records whose cases the sweep had just run (3.5 min). You can see this live on run 38094461851: every other job finished by 23:43, while Db2 kept the refresh waiting.

Change (evidence-refresh.yml only):

• db2-part: a 5-leg matrix, each leg with its own Db2. Four legs run proof_sweep.py --det-only --db2-only --shard I/4 --no-ratchet, balanced by det_sweep_durations.json; the fifth leg re-proves the stale Db2 records in parallel with them.
• db2 (new, thin): downloads the parts, then proof_sweep.py --aggregate <shards> --expect db2 --skip-ledger-check. That is the same ratchet as before, applied to the merge, so a shard that died fails it. It keeps the job's old outputs (sweep_ok, sha) and the db2-results artifact, so the refresh job barely changes.
• refresh: hands every Db2 shard's sweep.json to det_coverage_ledger.py update (it already takes several).

Checked locally:

• actionlint is clean (private venv).
• The YAML parses, with jobs lane, db2-part, db2, sweep, records, refresh.
• Shard balance for the 38 Db2 cases: 9 / 9 / 10 / 10 cases, about 490–515 s of recorded duration each.
• The merge was replayed on the nightly's real Db2 sweep.json, split as the shards would split it: all 4 shards → "as expected", exit 0; shard 3 missing → 10 cases "no result", exit 1.
• pr_gates.py --fast: 5/5 pass.
• 499 workflow and evidence tests pass. The 2 failures are committed … is current checks on generated pages, which are already out of date on main since CICS: DOCUMENT CREATE / RETRIEVE in both runtimes and both translators (Part of #4769) #4858 and advisory in CI.

Expected: each shard about 2.5 min of setup + its estates + about 6.5 min of sweep; the records leg about 7 min; the merge about 2 min. The Db2 path should drop from about 34 min to about 13–15, roughly level with the non-Db2 sweep shards, so the refresh ends in about 20 min instead of about 37. The cost is 5 runner starts and Db2 image pulls instead of 1.

Not done:

• Caching the generated estates between nights: their cache key is every file under gitgalaxy/, which changes on nearly every merge, so it would rarely hit.
• Per-scenario overhead (one long-lived Db2 session per case) and content-keyed skips: later steps in Evidence refresh: re-measure translation every night (the reports' survey froze on 2026-10-07) #4863, measure first.

Proving it on CI: this workflow runs nightly or on dispatch only. After merge, dispatch gh workflow run "Evidence Refresh" -R squid-protocol/gitgalaxy (db2 = true) and compare the db2-part and db2 timings with 34 min.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MhEx8PwSow3Pyfg6J4KZ97

[squid-protocol]

No description provided.

[squid-protocol]

No description provided.

[squid-protocol]

No description provided.

[github-actions]

🐦‍⬛ Muninn Security Scan

✅ No security issues found.

🐦‍⬛ Powered by Muninn · Skald Lab