fix: fetch.mpack.prebuild rebuilds when superseded mid-build
Found live during the Bug B bulk commit-signature repair (musehub#108): a single coalesced prebuild job was already mid-build when 20 repair-commit calls landed; only 1 of 20 made it into the job's cached mpack, because its data read had started before the other 19 writes committed. The next fresh clone served that stale-but-cached mpack, silently missing 19 real repairs even though every one of them was correctly persisted server-side (verified directly against musehub_commits -- the repair script and wire_repair_commit are not at fault here).
This is the sharp edge of MWP9's own dedup fix: treating a 'running' fetch.mpack.prebuild as already covering a new trigger is only true if the running job's read happens *after* the trigger's write -- not guaranteed once a build can take 30-100+s.
Fix: enqueue_job now stamps superseded_at on the existing 'running' row when it dedup-skips a new trigger against it. process_fetch_mpack_prebuild_job checks its own superseded_at after each build attempt (bounded at 3 tries) and forces one more full rebuild if it was stamped during the build it just finished, before writing the final cache entry. A sustained stream of concurrent triggers can still exhaust the retry budget -- that's accepted and self-heals via the next unrelated trigger, same as any eventually- consistent cache.
Migration 0078 adds the nullable superseded_at column (additive, no backfill needed -- historical rows default to never-superseded).
Semantic Changes
17 symbols
Files Changed
+1
~5
1085 in snapshot
0 comments
muse hub commit comment sha256:388b0d5926748aed8e7b2941523f5fb2b6991d500eea4c3aac01c5e1e07d2d86 --body "your comment"
No comments yet. Be the first to start the discussion.