Skip to content

feat(orchestrator): migrate the buildsignal poll loop to the hold primitive - #489

Draft
behinddwalls wants to merge 1 commit into
preetam/hold-migrate-stovepipefrom
preetam/hold-migrate-orchestrator
Draft

feat(orchestrator): migrate the buildsignal poll loop to the hold primitive#489
behinddwalls wants to merge 1 commit into
preetam/hold-migrate-stovepipefrom
preetam/hold-migrate-orchestrator

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Aug 1, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

The orchestrator's buildsignal stage carried the same ack-and-republish poll loop the stovepipe stages just migrated off (previous commit): each non-terminal poll acked the delivery and PublishAfter'd the build id back to its own topic. Notably its republish reused the build id as the message id — the exact dedup collision that stalled stovepipe's loop (#465) was latent here — and a transient publish failure was wrapped retryable as the loop's only liveness, the awkward classification #469 removed on the stovepipe side.

What?

A non-terminal status now records a hold for the per-status poll delay and returns success; the framework postpones the delivery, which redelivers without counting toward the retry limit. publishBuild is deleted (the re-poll was its only caller); the speculate publish and halted-batch short-circuit are unchanged, and the DLQ reconciler is unaffected. The Process retryability comment is rewritten: the loop's continuation is framework-owned, so no publish needs a retryable wrap. build-runner.md's "Polling primitive" section is updated — hold supersedes the PublishAfter design it argued for, keeping the same retry_count semantics with no publisher, no minted ids, and no per-tick rows.

Test Plan

bazel test //submitqueue/... — NonTerminal cases assert Hold(per-status delay); Terminal/StatusError/UpdateStatusError/Halted cases fail on any Hold; the RepublishError test is deleted (a hold cannot fail). ✅ make fmt.

Stack

  1. docs(rfc): consumer hold — postpone a delivery as a partition barrier #486
  2. feat(platform): hold/postpone — a fourth delivery outcome for backing off #487
  3. feat(stovepipe): migrate process and buildsignal waits to the hold primitive #488
  4. @ feat(orchestrator): migrate the buildsignal poll loop to the hold primitive #489
  5. feat(messagequeue)!: remove PublishAfter and the visible_after column #490
  6. feat(messagequeue)!: drop the requeue delay parameter from Nack #491
  7. feat(consumergate)!: rebuild the gate on the postpone primitive #492

…mitive

## Summary

### Why?

The orchestrator's buildsignal stage carried the same ack-and-republish poll loop the stovepipe stages just migrated off (previous commit): each non-terminal poll acked the delivery and PublishAfter'd the build id back to its own topic. Notably its republish reused the build id as the message id — the exact dedup collision that stalled stovepipe's loop (#465) was latent here — and a transient publish failure was wrapped retryable as the loop's only liveness, the awkward classification #469 removed on the stovepipe side.

### What?

A non-terminal status now records a hold for the per-status poll delay and returns success; the framework postpones the delivery, which redelivers without counting toward the retry limit. publishBuild is deleted (the re-poll was its only caller); the speculate publish and halted-batch short-circuit are unchanged, and the DLQ reconciler is unaffected. The Process retryability comment is rewritten: the loop's continuation is framework-owned, so no publish needs a retryable wrap. build-runner.md's "Polling primitive" section is updated — hold supersedes the PublishAfter design it argued for, keeping the same retry_count semantics with no publisher, no minted ids, and no per-tick rows.

## Test Plan

✅ `bazel test //submitqueue/...` — NonTerminal cases assert Hold(per-status delay); Terminal/StatusError/UpdateStatusError/Halted cases fail on any Hold; the RepublishError test is deleted (a hold cannot fail). ✅ `make fmt`.
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.

1 participant