fix: dedup fetch.mpack.prebuild against running jobs, not just pending
rc10 object-store migration corrupted signer_public_key/signature on 1179+ commits (muse#108). The repair mechanism (wire_repair_commit) works, but running a bulk repair batch against it flooded the background job queue: fetch.mpack.prebuild is self-coalescing (re-reads live branch tips at run time) but every enqueue site only deduped against status=pending, never running. A rebuild takes 30-100+s, so repeated triggers during that window (repair-commit calls, or just rapid pushes) each queued a redundant full rebuild, starving ordinary clone/fetch requests past their 120s retry budget -- confirmed live: 3 of 5 concurrent clone attempts failed outright during a 184-commit repair run.
Adds a dedup_statuses param to enqueue_job (default unchanged: pending only) and scopes pending+running dedup narrowly to fetch.mpack.prebuild at both enqueue sites (_enqueue_repair_prebuild and enqueue_push_intel's coarse dedup). Other coarse job types keep the original pending-only window since they aren't confirmed self-coalescing.
Also adds deploy/repair_commit_signatures.py, the bulk repair driver used to find this, with TDD coverage for its WireCommit payload projection (including an exhaustiveness guard against WireCommit's nullable-string fields -- a live 422 on agent_id/model_id was caught this way).
Semantic Changes
60 symbols
Files Changed
+3
~2
1084 in snapshot
0 comments
muse hub commit comment sha256:195787044debd61f93cc31b92754ee0f78e1b6f66757ee07ea5058ed5ce5197d --body "your comment"
No comments yet. Be the first to start the discussion.