Skip to content

feat(stovepipe): reconcile dead-lettered build signals and free the slot - #565

Merged
mnoah1 merged 2 commits into
mainfrom
mnoah1/stovepipe-buildsignal-dlq
Aug 11, 2026
Merged

feat(stovepipe): reconcile dead-lettered build signals and free the slot#565
mnoah1 merged 2 commits into
mainfrom
mnoah1/stovepipe-buildsignal-dlq

Conversation

@mnoah1

@mnoah1 mnoah1 commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

What?

Add buildsignal dlq controller implementation

Why?

A buildsignal message that dead-letters ends the only poll chain watching a build that is still running, and its request keeps holding one of the queue's in_flight_count slots. With no reconciler on that topic the count stays high for good, so the queue loses a slot per incident until it can no longer admit work.

Add the buildsignal DLQ controller, which maps the dead-lettered build back to its request, marks the request failed, and releases the slot, and register it plus its topic in the reference server.

Also document in the RFC that the stage's "classifier decides" disposition for Status failures only works if the BuildRunner backend classifies its own transport and HTTP errors. Unclassified, they take the non-retryable default, which is what sends a poll message to the DLQ on the first proxy blip.

Test Plan

  • Integrate in go-code's stovepipe service
  • Monitor for cases of buildsignal remaining stuck on a poll error

@mnoah1
mnoah1 marked this pull request as ready for review August 11, 2026 15:06
@mnoah1
mnoah1 requested review from a team, behinddwalls and sbalabanov as code owners August 11, 2026 15:06
@mnoah1
mnoah1 enabled auto-merge August 11, 2026 15:18
Comment thread stovepipe/controller/dlq/buildsignal.go
mnoah1 added 2 commits August 11, 2026 21:33
A buildsignal message that dead-letters ends the only poll chain watching a
build that is still running, and its request keeps holding one of the queue's
in_flight_count slots. With no reconciler on that topic the count stays high for
good, so the queue loses a slot per incident until it can no longer admit work.

Add the buildsignal DLQ controller, which maps the dead-lettered build back to
its request, marks the request failed, and releases the slot, and register it
plus its topic in the reference server.

Also document in the RFC that the stage's "classifier decides" disposition for
Status failures only works if the BuildRunner backend classifies its own
transport and HTTP errors. Unclassified, they take the non-retryable default,
which is what sends a poll message to the DLQ on the first proxy blip.
Review question on the buildsignal reconciler: failRequest releases the queue
slot only for a request in processing, so does it need to widen that?

It does not. Processing is the only non-terminal state that can own a slot:
process claims the slot and CAS-marks accepted->processing, compensating its own
claim when that CAS does not land, and processing exits only to a terminal
outcome, which releases the slot itself. Releasing for accepted would decrement
for the common request that never claimed one, over-admitting against
MaxConcurrent. Say that where failRequest gates on the state, note at the
buildsignal call site that a build row implies processing-or-terminal, and pin
the intent on the accepted test case, which passes no queue expectations.
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-buildsignal-dlq branch from 085d43c to 232a133 Compare August 11, 2026 21:33
@mnoah1
mnoah1 added this pull request to the merge queue Aug 11, 2026
Merged via the queue into main with commit a60a7b4 Aug 11, 2026
25 of 27 checks passed
@mnoah1
mnoah1 deployed to stack-rebase August 11, 2026 22:44 — with GitHub Actions Active
@behinddwalls
behinddwalls deleted the mnoah1/stovepipe-buildsignal-dlq branch August 11, 2026 22:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants