Repository navigation
feat(stovepipe): store fixer submissions per issue and backend - #1032
Merged
Merged
Conversation
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
prathshenoy
approved these changes
Nov 10, 2026
Summary: Add versioned repair records keyed by issue opening and executor, with accepted fix IDs, terminal skip reasons, and executor-owned map metadata. This storage foundation preserves existing dispatch behavior; batch dispatch and recovery follow together in the next PR. Test Plan: Run the Stovepipe and reference-server Bazel tests, including repair-state persistence, metadata round trips, and version conflict coverage. Run lint, tidy, Gazelle, and mock generation checks. GitHub CI validates all builds and integration tests. Revert Plan: Revert the dependent fixer behavior change first, then revert this PR. The additive table can remain.
mnoah1
force-pushed
the
mnoah1/stovepipe-repair-state
branch
from
November 10, 2026 17:13
cc05954 to
a0c8c3a
Compare
Tmwakalasya
pushed a commit
to Tmwakalasya/submitqueue
that referenced
this pull request
Nov 11, 2026
…ds (uber#1033) ## 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 `Submit` call. Each backend chooses how to group submissions and enforce its own limits; a failure in one backend does not suppress another. Extend the fixer contract to return stable, named executor registrations and accept batches of issue openings. Each submission receipt identifies an accepted fix ID or terminal skip; several issues may share one fix ID. Create pending repair rows before submission, retain valid receipts even alongside errors, preserve executor metadata through versioned updates, and restore history on replay without resubmitting durable outcomes. Migrate the controller, reference-server wiring, and DLQ recovery together to the storage from uber#1032. DLQ recovery restores every durable acceptance or skip, records unknown acceptance for pending work, and never submits repair work. ## Test Plan `./tool/bazel test //stovepipe/... //service/stovepipe/server:go_default_test --test_output=errors` passes all 30 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, preserved retry classification, and DLQ recovery of accepted, skipped, and unknown outcomes without submitting work. Local lint, module-tidy, Gazelle, and mock-generation checks pass. Full repository Bazel build (`./tool/bazel build //...`) passes all 643 targets, including both web images. ## Revert Plan Revert this PR as one unit to restore the previous fixer contract, dispatch, and DLQ recovery behavior. The storage foundation in uber#1032 and its additive table can remain. ## Issue Links None — completes the fixer extension on top of uber#1032; no issue was provided. ## Stack 1. uber#1032 1. @ uber#1033
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 fixer flow stores one fix ID on a build issue. That cannot independently track several backends repairing the same issue opening, or retain backend metadata before a submission is accepted. Extending the fixer to multiple issues and backends needs durable state for each issue/backend pair.
What?
Add an
IssueRepairrecord and queue-scoped store keyed by issue opening and executor ID, with a MySQL schema, generated mocks, and storage tests. Each row retains an accepted fix ID or terminal skip reason, executor-ownedmap[string]stringmetadata, and a version for conditional updates. Empty fix ID and skip reason mean the submission is pending.This PR provides the storage foundation while preserving existing dispatch behavior. #1033 extends the fixer contract, dispatch, and DLQ recovery together to use these records independently for each backend.
Test Plan
./tool/bazel test //stovepipe/... //service/stovepipe/server:go_default_test --test_output=errorspasses all 30 targets, including pending creation, metadata round trips, accepted/skipped updates, stale-version rejection, and existing service wiring. Local lint, module-tidy, Gazelle, and mock-generation checks pass.Full repository Bazel build (
./tool/bazel build //...) passes all 643 targets, including both web images.Revert Plan
Revert dependent dispatcher changes first, then revert this PR. The additive table can remain.
Issue Links
None — storage foundation for #1033; no issue was provided.
Stack