Skip to content

fix(stovepipe): stop wrapping the buildsignal re-poll publish as retryable - #469

Merged
behinddwalls merged 1 commit into
mainfrom
preetam/stovepipe-publish-classification
Jul 30, 2026
Merged

fix(stovepipe): stop wrapping the buildsignal re-poll publish as retryable#469
behinddwalls merged 1 commit into
mainfrom
preetam/stovepipe-publish-classification

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Summary

Why?

buildsignal wrapped a failed reschedule publish in errs.NewRetryableError. platform/errs rule 4 says not to do that: a failed queue publish must not be made retryable just because replaying it is convenient, because that turns a permanent enqueue failure into an infinite retry instead of dead-lettering. It was also inconsistent with the sibling path — the publish to record, one branch above, already returns raw.

What?

Returns the raw error, leaving the classifier's verdict to stand, and drops the now-unused errs dependency.

Merge ordering

This should merge only after the build and buildsignal stages have DLQ consumers. Today only stovepipe-process-dlq is registered, and MoveToDLQ routes by topic-suffix convention, so anything dead-lettered from buildsignal lands on buildsignal_dlq and is never drained — leaving the request non-terminal with its build slot held, which is the wedge the reconciler exists to prevent.

This change does not create that hole; every other non-retryable failure in the stage already falls into it. But it does add one more path in, so the ordering is worth respecting rather than discovering later. If the DLQ work slips, the alternative is to land this anyway and accept parity with the existing failure modes.

Test Plan

✅ bazel test //stovepipe/... — the reschedule-publish-failure case now asserts a non-retryable classification.

✅ bazel test //test/e2e/stovepipe/... — the poll loop is unaffected on the success path.

Stack

  1. test(stovepipe): add build-slow marker to the fake build runner #464
  2. fix(stovepipe): mint a distinct message id for each buildsignal re-poll #465
  3. refactor(stovepipe): replace recorded greenness states with build outcomes #466
  4. feat(stovepipe): record the build outcome on the request and free its slot #467
  5. feat(stovepipe)!: key the record stage on the request id #468
  6. @ fix(stovepipe): stop wrapping the buildsignal re-poll publish as retryable #469

This was referenced Jul 29, 2026
Merged
Merged
Merged
Merged
Merged
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 16f5390 to 2ae86d2 Compare July 29, 2026 22:41
@behinddwalls
behinddwalls marked this pull request as ready for review July 29, 2026 23:10
@behinddwalls
behinddwalls requested review from a team and sbalabanov as code owners July 29, 2026 23:10
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 2ae86d2 to 71366e3 Compare July 30, 2026 07:51
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 71366e3 to 851c054 Compare July 30, 2026 18:20
@behinddwalls
behinddwalls added this pull request to the merge queue Jul 30, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue because the pull requests in the stack were not ordered correctly in the queue Jul 30, 2026
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 851c054 to 1d12ffe Compare July 30, 2026 18:31
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 1d12ffe to 21a0e7c Compare July 30, 2026 19:57
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 21a0e7c to 92999dd Compare July 30, 2026 20:09
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 92999dd to 1147e6d Compare July 30, 2026 20:15
Base automatically changed from preetam/stovepipe-record-request-id to main July 30, 2026 20:22
@behinddwalls
fix(stovepipe): stop wrapping the buildsignal re-poll publish as retr…
0c60982 
…yable

## Summary

### Why?

`buildsignal` wrapped a failed reschedule publish in `errs.NewRetryableError`. `platform/errs` rule 4 says not to do that: a failed queue publish must not be made retryable just because replaying it is convenient, because that turns a permanent enqueue failure into an infinite retry instead of dead-lettering. It was also inconsistent with the sibling path — the publish to `record`, one branch above, already returns raw.

### What?

Returns the raw error, leaving the classifier's verdict to stand, and drops the now-unused `errs` dependency.

### Merge ordering

**This should merge only after the build and buildsignal stages have DLQ consumers.** Today only `stovepipe-process-dlq` is registered, and `MoveToDLQ` routes by topic-suffix convention, so anything dead-lettered from `buildsignal` lands on `buildsignal_dlq` and is never drained — leaving the request non-terminal with its build slot held, which is the wedge the reconciler exists to prevent.

This change does not create that hole; every other non-retryable failure in the stage already falls into it. But it does add one more path in, so the ordering is worth respecting rather than discovering later. If the DLQ work slips, the alternative is to land this anyway and accept parity with the existing failure modes.

## Test Plan

✅ `bazel test //stovepipe/...` — the reschedule-publish-failure case now asserts a non-retryable classification.

✅ `bazel test //test/e2e/stovepipe/...` — the poll loop is unaffected on the success path.

# Conflicts:
#	stovepipe/controller/buildsignal/buildsignal.go

# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
#
# interactive rebase in progress; onto 4199281
# Last command done (1 command done):
#    pick 356f028d fix(stovepipe): stop wrapping the buildsignal re-poll publish as retryable
# No commands remaining.
# You are currently rebasing branch 'preetam/stovepipe-publish-classification' on '41992811'.
#
# Changes to be committed:
#	modified:   doc/rfc/stovepipe/steps/buildsignal.md
#	modified:   stovepipe/controller/buildsignal/BUILD.bazel
#	modified:   stovepipe/controller/buildsignal/buildsignal.go
#	modified:   stovepipe/controller/buildsignal/buildsignal_test.go
#
@behinddwalls
behinddwalls force-pushed the preetam/stovepipe-publish-classification branch from 1147e6d to 0c60982 Compare July 30, 2026 20:22
@behinddwalls
behinddwalls added this pull request to the merge queue Jul 30, 2026
Merged via the queue into main with commit 8f2b134 Jul 30, 2026
15 checks passed
behinddwalls added a commit that referenced this pull request Jul 30, 2026
@behinddwalls
ci(rebase-stack): skip native gh-stacks, re-enable for the rest
5539be8 
## Summary

### Why?

PR #443 disabled this workflow outright (`if: false`) when the repo moved to GitHub's native stacked PRs. That was too blunt: native stacks and hand-rolled `arh` chains coexist here today. Stacks #470, #472 and #474 are native, while #460 → #461 → #462 → #463 → #476 is a plain chain whose every member reports `stack: null`. With the workflow off, merging any PR in a hand-rolled chain leaves the children still carrying their parent's commits — precisely the broken-diff problem this workflow was written to fix.

GitHub owns the lifecycle of its own stacks: on a partial merge it rebases and retargets the surviving members itself, so the workflow must not touch those. It only needs to tell the two apart rather than give up on both.

### What?

Re-enables the job and skips only the PRs GitHub actually owns, instead of switching the whole workflow off.

A `detect_stack` helper resolves native-stack membership from `GET /repos/{owner}/{repo}/pulls/{n}`. It queries the REST API at run time rather than reading `github.event.pull_request.stack` off the webhook payload, so a PR added to a stack after the merge event was queued is still recognised. Membership survives merge — a merged member still reports its stack — which is what makes the lookup meaningful at this point in the lifecycle.

The check is applied **per child PR**, not to the merged PR. GitHub only ever rebases a stack's own members; a PR that targets a member's head branch without joining the stack is invisible to that machinery. Skipping the whole chain whenever the merged PR happened to be a stack member would therefore strand such a PR with exactly the broken diff this workflow exists to prevent. `rebase_chain` always runs; each child that is a stack member is skipped and not recursed into, while its siblings rebase normally. Membership of the merged PR is logged for context and gates nothing.

Presence is tested on the `stack` object itself rather than on `stack.number`. Probing a sub-field means a stack object arriving without that field reads as "standalone" and gets force-pushed — the unsafe direction to fail in. The number is used only for logging. An unreadable response still falls back to standalone, since the Stacks API 404s when the feature is not enabled for a repo, which is exactly when the rebase is wanted.

`cleanup_orphaned_merged_branches` still runs on every merge, including those where every child turned out to be GitHub's to rebase. This workflow therefore remains the sole owner of head-branch deletion, and native-stack head branches are reaped here too, each on the first merge after GitHub has retargeted its successors off it.

This depends on "Automatically delete head branches" being OFF, as the header has always documented — otherwise GitHub retargets children to `main` before the job runs and the non-native path silently no-ops on a green job. The setting has been turned off on the repo.

## Test Plan

✅ YAML parses; job `if` and step `env` verified after the edit.

✅ `bash -n` clean on the extracted `run:` block under bash 5.2, the version Actions runners use. Note for future edits: macOS `/bin/bash` 3.2 reports a spurious `syntax error near ';;'` on this script — it cannot parse the heredoc nested in `$( )`, so it blames a line far from the real construct.

✅ `actionlint` v1.7.7 — clean.

✅ `zizmor` v1.25.2 (`--no-online-audits`, the version CI pins) — no findings, 2 ignored and 5 suppressed, confirming the existing `.github/zizmor.yml` exceptions still cover the file.

✅ `yamlfmt` v0.16.0 `-lint` — clean.

✅ `detect_stack` exercised against live PRs in this repo:

| PR | `.stack` | Result |
| --- | --- | --- |
| #467 | stack #470, position 4/6, merged | native → skipped |
| #468 | stack #470, position 5/6, open | native → skipped |
| #404 | stack #472 | native → skipped |
| #457 | stack #475, size 1 | native → skipped |
| #443 | `null` | standalone → rebased |
| #460 | `null` | standalone → rebased |
| #999999 | HTTP 404 | warns, treated as standalone, no `set -euo pipefail` abort |

✅ The sub-field trap verified directly: a synthetic `{"stack":{"id":51488,"position":4,"size":6}}` with no `number` reads as standalone under `.stack.number // empty`, and as in-a-stack under the expression shipped here.

✅ Observed reference case — the merge of #467 (position 4 of stack #470). GitHub retargeted #468 from `preetam/stovepipe-buildsignal-outcome` to `main` and left #469 on #468's branch, confirming both that GitHub handles its own members and that a merged member retains its `stack` object.

The rebase itself can only be exercised post-merge. On the next merge of a hand-rolled chain (the runway series is the live case) watch for `=== Stack rebase complete ===` and a child retargeted with only its own commits; on a native-stack merge watch for each member child logging `skipped: belongs to native stack #N`, followed by the branch sweep. The first sweep will also reap `preetam/stovepipe-buildsignal-outcome`, which is currently orphaned — it merged after auto-delete was turned off and has no open dependents.
@behinddwalls behinddwalls mentioned this pull request Jul 30, 2026
Merged
behinddwalls added a commit that referenced this pull request Jul 30, 2026
@behinddwalls
ci(rebase-stack): skip native gh-stacks, re-enable for the rest (#478)
bebdb5d 
## Summary

### Why?

PR #443 disabled this workflow outright (`if: false`) when the repo
moved to GitHub's native stacked PRs. That was too blunt: native stacks
and hand-rolled `arh` chains coexist here today. Stacks #470, #472 and
#474 are native, while #460 → #461 → #462 → #463 → #476 is a plain chain
whose every member reports `stack: null`. With the workflow off, merging
any PR in a hand-rolled chain leaves the children still carrying their
parent's commits — precisely the broken-diff problem this workflow was
written to fix.

GitHub owns the lifecycle of its own stacks: on a partial merge it
rebases and retargets the surviving members itself, so the workflow must
not touch those. It only needs to tell the two apart rather than give up
on both.

### What?

Re-enables the job and skips only the PRs GitHub actually owns, instead
of switching the whole workflow off.

A `detect_stack` helper resolves native-stack membership from `GET
/repos/{owner}/{repo}/pulls/{n}`. It queries the REST API at run time
rather than reading `github.event.pull_request.stack` off the webhook
payload, so a PR added to a stack after the merge event was queued is
still recognised. Membership survives merge — a merged member still
reports its stack — which is what makes the lookup meaningful at this
point in the lifecycle.

The check is applied **per child PR**, not to the merged PR. GitHub only
ever rebases a stack's own members; a PR that targets a member's head
branch without joining the stack is invisible to that machinery.
Skipping the whole chain whenever the merged PR happened to be a stack
member would therefore strand such a PR with exactly the broken diff
this workflow exists to prevent. `rebase_chain` always runs; each child
that is a stack member is skipped and not recursed into, while its
siblings rebase normally. Membership of the merged PR is logged for
context and gates nothing.

Presence is tested on the `stack` object itself rather than on
`stack.number`. Probing a sub-field means a stack object arriving
without that field reads as "standalone" and gets force-pushed — the
unsafe direction to fail in. The number is used only for logging. An
unreadable response still falls back to standalone, since the Stacks API
404s when the feature is not enabled for a repo, which is exactly when
the rebase is wanted.

`cleanup_orphaned_merged_branches` still runs on every merge, including
those where every child turned out to be GitHub's to rebase. This
workflow therefore remains the sole owner of head-branch deletion, and
native-stack head branches are reaped here too, each on the first merge
after GitHub has retargeted its successors off it.

This depends on "Automatically delete head branches" being OFF, as the
header has always documented — otherwise GitHub retargets children to
`main` before the job runs and the non-native path silently no-ops on a
green job. The setting has been turned off on the repo.

## Test Plan

✅ YAML parses; job `if` and step `env` verified after the edit.

✅ `bash -n` clean on the extracted `run:` block under bash 5.2, the
version Actions runners use. Note for future edits: macOS `/bin/bash`
3.2 reports a spurious `syntax error near ';;'` on this script — it
cannot parse the heredoc nested in `$( )`, so it blames a line far from
the real construct.

✅ `actionlint` v1.7.7 — clean.

✅ `zizmor` v1.25.2 (`--no-online-audits`, the version CI pins) — no
findings, 2 ignored and 5 suppressed, confirming the existing
`.github/zizmor.yml` exceptions still cover the file.

✅ `yamlfmt` v0.16.0 `-lint` — clean.

✅ `detect_stack` exercised against live PRs in this repo:

| PR | `.stack` | Result |
| --- | --- | --- |
| #467 | stack #470, position 4/6, merged | native → skipped |
| #468 | stack #470, position 5/6, open | native → skipped |
| #404 | stack #472 | native → skipped |
| #457 | stack #475, size 1 | native → skipped |
| #443 | `null` | standalone → rebased |
| #460 | `null` | standalone → rebased |
| #999999 | HTTP 404 | warns, treated as standalone, no `set -euo
pipefail` abort |

✅ The sub-field trap verified directly: a synthetic
`{"stack":{"id":51488,"position":4,"size":6}}` with no `number` reads as
standalone under `.stack.number // empty`, and as in-a-stack under the
expression shipped here.

✅ Observed reference case — the merge of #467 (position 4 of stack
#470). GitHub retargeted #468 from
`preetam/stovepipe-buildsignal-outcome` to `main` and left #469 on
#468's branch, confirming both that GitHub handles its own members and
that a merged member retains its `stack` object.

The rebase itself can only be exercised post-merge. On the next merge of
a hand-rolled chain (the runway series is the live case) watch for `===
Stack rebase complete ===` and a child retargeted with only its own
commits; on a native-stack merge watch for each member child logging
`skipped: belongs to native stack #N`, followed by the branch sweep. The
first sweep will also reap `preetam/stovepipe-buildsignal-outcome`,
which is currently orphaned — it merged after auto-delete was turned off
and has no open dependents.
@behinddwalls
behinddwalls deleted the preetam/stovepipe-publish-classification branch July 30, 2026 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mnoah1 mnoah1 mnoah1 approved these changes
@sbalabanov sbalabanov Awaiting requested review from sbalabanov sbalabanov is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@behinddwalls @mnoah1