Repository navigation
Conversation
Summary: Offer each registered executor all outstanding issue openings in one batch. Persist pending rows before dispatch and retain per-item acceptance or skips while preserving executor metadata through versioned updates. Restore durable history on replay and preserve independent error causes and valid partial receipts. This builds on the batch executor contract. The existing DLQ behavior remains in place until the next PR migrates recovery to per-executor repair records. Test Plan: `./tool/bazel test //stovepipe/... //service/stovepipe/server:go_default_test --test_output=errors` exercises 28 targets covering batching across pages, multiple executors, partial acceptance, failed writes, version conflicts, history replay, and preservation of retry classification. Lint, tidy, and Gazelle checks verify the repository metadata. Revert Plan: Revert the dependent DLQ change first, then revert this PR together with its executor-contract prerequisite.
mnoah1
force-pushed
the
mnoah1/stovepipe-batch-repairs
branch
from
November 6, 2026 22:11
05e1426 to
1148984
Compare
mnoah1
changed the base branch from
mnoah1/stovepipe-repair-state
to
mnoah1/stovepipe-fixer-contract
November 6, 2026 22:11
This was referenced Nov 6, 2026
mnoah1
changed the title
mnoah1
marked this pull request as ready for review
November 6, 2026 22:31
mnoah1
requested review from
a team,
behinddwalls and
sbalabanov
as code owners
November 6, 2026 22:31
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why?
The existing fix controller selects one eligible issue and suppresses further submissions once any issue in the build has a fix ID. That build-wide limit prevents newly opened issues and additional fixer backends from receiving independent repair requests.
What?
Replace the build-wide gate with eligibility per issue opening and executor. Read every page of the build's observations, select still-open issues first seen in that build, and offer each registered executor all of its pending issues in one
Submitcall. Each backend chooses how to group submissions and enforce its own limits; a failure in one backend does not suppress another.Create pending repair rows before submission, retain valid acceptance and skip receipts even alongside errors, preserve executor metadata through versioned updates, and restore history on replay without resubmitting durable outcomes. This applies the API from #1034 and storage from #1032 to the existing controller and reference-server wiring. DLQ recovery is extended separately in #1035.
Test Plan
./tool/bazel test //stovepipe/... //service/stovepipe/server:go_default_test --test_output=errorscovers 28 test targets. The fix-controller tests exercise paginated batches, independent backends, partial acceptance, failed pending writes preventing dispatch, metadata preservation during version conflicts, retry without resubmitting durable outcomes, and preserved retry classification. Local lint, module-tidy, and Gazelle checks also completed.Revert Plan
Revert #1035 first, then revert this PR together with #1034. The additive repair-state schema can remain.
Issue Links
No issue was provided. Part 3 of the repair-executor stack; based on #1034. DLQ recovery follows in #1035.
Stack