feat(runway): reject changes that disagree on provider by behinddwalls · Pull Request #476 · uber/submitqueue

behinddwalls · 2026-07-30T17:36:24Z

Summary

Why?

The merger decides which provider a change came from by its URI scheme, and rejects a scheme it has no parser for. That part works, and it happens before any git command runs.

What it does not do is check that the changes in one request agree with each other. resolveChange determines the provider per URI and then discards it, so a request whose steps are addressed through different providers is resolved by different parsers and applied as though nothing were unusual. SubmitQueue already refuses that within a single change, but a Runway request carries one step per SubmitQueue request, so nothing covers the request as a whole.

What?

Keeps Provider on changeRef — the scheme the change was addressed through — rather than parsing it and throwing it away.

resolveAndValidate now compares every change against the first and rejects a request that mixes providers, naming both and the steps they came from. It already walked every URI to validate it, and it runs before the mutex and before any git command, so an incoherent request costs nothing and leaves the checkout untouched.

This cannot refuse a legitimate request: there is no way to address one merge through two providers, and the apply paths would otherwise have to reason about changes resolved by different parsers.

Also names the change, not just the commit, in the unavailable-commit error, so the reader is not sent looking for a deleted commit when the likelier cause is a change this remote was never going to serve.

Whether a change belongs to the repository this merger serves is deliberately not checked. The merger is already constrained to its checkout and remote by configuration, and a change it cannot fetch is refused on those grounds.

Test Plan

✅ bazel test //runway/... — all targets pass (git suite 70s)
✅ make lint, make check-tidy, make check-gazelle, make test

New cases: two steps using different providers, one change spanning two providers, and an unsupported provider — each asserted terminal and not a conflict. A multi-step multi-URI request through one provider is asserted to still succeed, guarding against over-rejecting.

The rejection cases run against a Merger whose git executable does not exist, so any git invocation would fail as an exec error. Getting ErrInvalidRequest back proves the request was refused before the merger reached for git.

Issues

Stack

behinddwalls · 2026-07-30T18:14:36Z

+	// Repo canonically identifies the repository the change lives in, host
+	// included, so that two changes can be compared without caring which
+	// provider spelled them. Every change in one request must agree on it.
+	Repo string


i think we can drop this, for now I was mostly concerned about merger's ability to fetch the changes using git for say github PRs...so if we put a constraint on it, it's enough

Done — dropped Repo and the repository comparison, kept the provider one.

To be explicit about where that leaves things, since the two were doing different jobs:

Fetching GitHub PRs — your original concern — is handled in feat(runway): git-backed merger with REBASE #460 and is unchanged: each referenced commit is fetched by SHA (falling back to refs/pull/<n>/head) and verified present before any step is applied.

The merger is constrained to its checkout, remote and target by configuration. A change it cannot fetch is refused on those grounds, which is the constraint you're pointing at.

What's left here is only that one request cannot mix providers. It costs nothing — resolveAndValidate already walks every URI — and it keeps the apply paths from having to reason about changes resolved by different parsers.

I also kept the error-message change: the unavailable-commit error now names the change rather than just the commit, so it doesn't read as a deleted commit when the real cause is a change this remote was never going to serve.

The PR title narrowed to match ("reject changes that disagree on provider"). Head is now b9c16551.

## Summary ### Why? SubmitQueue records in-flight merge work before publishing and then waits for exactly one `MergeResult` echoing its correlation id. Runway is stateless and the sole responder on that id, so every request must resolve to a result — or the client waits forever. The primary controllers resolve what they can name: conflicts and invalid requests become a `FAILED` result, infrastructure faults are nacked for retry. But a fault that never recovers exhausts the retry budget and dead-letters. Nothing consumed those dead-letter topics, so the request produced no signal at all and the client's correlation id hung indefinitely. ### What? Adds `runway/controller/dlq`, a reconciler that subscribes to an inbound topic's `_dlq` queue and, for each dead-lettered `MergeRequest`, republishes a `FAILED` `MergeResult` echoing the correlation id to the corresponding signal topic. `dlq.TopicKey` derives the DLQ topic key from the primary one so the two stay in lockstep. Unlike the SubmitQueue and Stovepipe DLQ reconcilers this one writes no entity state — Runway has none, and the signal *is* the resolution. A payload that cannot be decoded carries no correlation id and is dropped rather than retried forever. Wires two instances in the server (one per inbound topic) on a dedicated consumer running under `errs.AlwaysRetryableProcessor`, so a transient publish failure retries indefinitely rather than dead-lettering the dead-letter. The DLQ consumer is started alongside the primary one and stopped with the same 30s drain on shutdown; both stop errors are joined into the exit status. ## Test Plan ✅ `bazel test //runway/...` — 5/5 pass, including new `//runway/controller/dlq` coverage for republish-on-dead-letter, the drop-undecodable-payload path, and publish-failure propagation ✅ `bazel build //service/runway/...` — wiring compiles ✅ `make gazelle`, `make fmt` ## Stack 1. @ #459 1. #460 1. #461 1. #462 1. #463 1. #476 1. #477

## 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.

## Summary ### Why? Runway's `merger` extension has had exactly one implementation — `noop`, which always succeeds. Nothing actually merges anything. This lands the first real backend: a `Merger` driven by the `git` CLI against a local checkout. It ships REBASE only. The strategy-specific apply paths are small and independent, but the machinery underneath them — the pinned git runtime, object resolution, the reset/apply/push cycle, contention retry, dry-run discard, conflict classification — is shared and is the bulk of what needs review. Landing it with one strategy keeps that review separable from the per-strategy mechanics that follow in this stack. ### What? Adds `runway/extension/merger/git`. **A change is a range of commits, not a commit.** A change URI pins a pull request to a single head SHA, but a pull request is routinely several commits. Applying the head alone applies only that commit's diff against its own parent: it conflicts against context its predecessors would have established, or — when the commits touch different files — succeeds while silently dropping everything before the head. So the unit replayed is the range from the change's merge base with the target up to its head. A change already contained in the target has an empty range and is a no-op, which is what keeps redelivery idempotent. A range runs through git's sequencer, which changes the control flow versus a single pick: the operation stops on a commit it declines and `--skip` advances to the next rather than ending. Two kinds of commit stop it harmlessly — one already present on the target, and one that was empty to begin with — and both are skipped. Anything else is a real conflict, and the in-progress pick is aborted so the checkout stays usable. The commits an apply produced are read back off the checkout rather than tracked per-invocation, which stays correct when the sequencer drops some. **Referenced commits are guaranteed present before anything is applied.** The default fetch refspec is `+refs/heads/*`, which does not cover a provider's change refs: a pull request head never also pushed as a branch — the normal case for a fork — is simply absent, and the apply then fails with git's "bad object", indistinguishable from a conflict. Every commit the request names is now fetched and verified up front, for all steps, so an unusable request fails without having mutated the checkout. Commits are requested by SHA (relying on the server serving a want for a reachable-but-unadvertised object, which github.com allows), falling back to the provider's canonical ref, with deployment-supplied refspecs as a last resort. Neither fetch is shallow — the range needs ancestry. A commit a *reachable* remote cannot supply is terminal; a remote that will not answer stays retryable. The first is a property of the request, the second a property of the moment. **One seam for change providers.** Every URI is reduced to the only three things the merger needs — the commit to apply, the ref the provider publishes it under, and a label for synthesized messages. `github://` and `git://` are supported; an unrecognized scheme is terminal. Adding a provider is one case in that mapping rather than a change to any apply path. **Optional staleness check.** Fetching by SHA guarantees the merger applies exactly the commit the URI names, not that it is still the change's head — a force-push leaves the superseded commit fetchable on most hosts. When enabled, each change's canonical ref is read (one ref advertisement, no object transfer) and a mismatch is terminal. **Atomicity, contention, dry run.** Nothing reaches the remote until the final push. If the push is rejected because the remote tip moved, the whole reset/apply/push cycle retries up to a bounded number of attempts. `CheckMergeability` runs the identical apply path but never pushes, then resets and reports empty outputs, committing intermediate steps locally so a multi-step check sees the same conflict surface a real merge would. **Runtime hygiene.** Every invocation uses an explicitly pinned git runtime and a scrubbed environment — no system or global config, no interactive prompts. That leaves no ambient identity, so the committer is injected per-invocation. `isConcreteStrategy` currently admits only REBASE; SQUASH_REBASE, MERGE and PROMOTE are rejected as invalid requests until their apply paths land later in this stack. The merger is not wired into the server yet, so this adds no production behavior. ## Test Plan ✅ `bazel test //runway/...` — 6/6 targets pass, including the new `//runway/extension/merger/git` suite (40s) The suite drives a real git binary against throwaway repositories. Beyond the single-commit cases (stacked URIs, already-landed changes, multi-step requests, conflicts, checkout recovery, contention retry, give-up after max attempts, DEFAULT resolution, dry runs), it covers what this change is actually about: a multi-commit change expressed as **one** URI for both disjoint and overlapping edits, a partially-landed change, an empty commit inside a range, a conflict inside a range leaving no sequencer state behind, stacked multi-commit changes not duplicating each other's commits, a head reachable only via its pull-request ref, an unavailable commit classified as invalid rather than conflicting, the staleness check on and off, and provider resolution across schemes. The regression tests were verified to fail against head-only picking: reverting just that line fails 5 of them, and they pass with the range applied. ## Stack 1. #459 1. @ #460 1. #461 1. #462 1. #463 1. #476 1. #477

## Summary ### Why? The git merger landed with REBASE only. `SQUASH_REBASE` and `MERGE` are part of the wire contract SubmitQueue already publishes against, and until they apply here a request naming either is rejected as an invalid request. This adds the two remaining transforming strategies on top of the shared apply machinery. ### What? **SQUASH_REBASE** applies each change exactly like REBASE — replaying every commit it introduces — then collapses what that change produced into a single commit. The squash unit is the change: a change of ten commits becomes one, and a step whose change carries several URIs yields one commit per URI. Those URIs are a stack of pull requests, and squashing them together would erase the per-PR boundary the stack exists to express. Two degenerate cases produce no output rather than an empty commit. A change already present on the target creates no commits, so there is nothing to squash. A change that does create commits whose net tree matches the base would squash to an empty commit, so the intermediates are dropped. Both keep redelivery idempotent. **MERGE** creates a `--no-ff` merge commit per change, which keeps the change's original commits reachable through second-parent history — the property that separates it from the picking strategies, which rewrite those hashes. A change already contained in HEAD is skipped rather than merged again. **Not every failed merge is a conflict.** `applyMerge` previously reported any `git merge` failure as `ErrConflict`, which tells the client its change collides with the target even when nothing collided. Failures are now classified, and the case that matters in practice is an unrelated history. **Importing an unrelated history.** A repository migration arrives as an ordinary change in the target repo whose branch carries the source repo's whole history. Being in the target repo is what makes the commits fetchable; it says nothing about ancestry, and git refuses to merge two graphs with no common ancestor. `AllowUnrelatedHistories` lifts that refusal for a queue that exists to perform such imports. It is off by default because the refusal is a genuine safeguard — with it always on, merging the wrong object silently produces a nonsense result instead of failing. Without the option, the refusal is now reported as an invalid request rather than a conflict. MERGE is the only strategy that can serve a migration: it is the only one that preserves the imported commits' original hashes, and the picking strategies have no range to compute across disjoint graphs, so they reject such a change explicitly and say so. ## Test Plan ✅ `bazel test //runway/extension/merger/git:go_default_test` — passes (58s) New coverage: SQUASH_REBASE collapsing a multi-commit change into one commit while landing all of its content, a two-URI change yielding one squashed commit per URI in application order, SQUASH_REBASE over an already-landed change producing none, MERGE creating one merge commit for a multi-commit change, MERGE skipping a change already an ancestor of the tip, and the MERGE dry-run path. For migration specifically: importing a three-commit unrelated history and asserting every imported commit is reachable **under its original hash**, the merge commit has two parents, and the target keeps its own files; redelivery of the same request being a no-op; the import rejected as an invalid request (explicitly not a conflict) when the option is off, leaving the remote and checkout untouched; and both picking strategies rejecting an unrelated history rather than rewriting it. ## Stack 1. #459 1. #460 1. @ #461 1. #462 1. #463 1. #476 1. #477

## Summary ### Why? `PROMOTE` is the last strategy in the wire contract without an apply path. It is also the one that does not fit the shared machinery: the transforming strategies build new commits locally and push `HEAD:target`, while PROMOTE advances the target to a commit that already exists, unchanged. ### What? Adds the `promote` path, dispatched directly from `process` rather than through `applyTransforming`. **Fast-forward only.** After resetting to the remote tip, promote classifies the named commit three ways. Already the tip, or contained in it — idempotent success, no push. A strict descendant of the tip — a genuine fast-forward, pushed as `<sha>:refs/heads/<target>`. Anything else has diverged and is a terminal `ErrConflict`; PROMOTE never creates a commit to reconcile the two. Because it moves the ref to an existing commit, a change of any size arrives whole by construction — its ancestry comes with it, so PROMOTE needs none of the range machinery the picking strategies do. **Exclusivity.** `resolveAndValidate` rejects a PROMOTE that is not the entire request — one step, one change, one URI — as `ErrInvalidRequest`. Two reasons, both structural: a pre-existing commit cannot descend from commits an earlier transforming step just produced, and the push targets an exact SHA rather than the locally-built HEAD, so there is nothing for a preceding step to contribute. **Its own availability checks.** promote bypasses `tryApply`, so it performs the object-availability and staleness checks itself. Without them a commit the remote cannot supply makes every containment query fail with a plain error, which the consumer retries forever rather than reporting a request that can never succeed. **Contention.** The same bounded retry as the transforming path, but the loop re-runs the classification rather than the apply: if the push is rejected the tip may have moved, and the commit that was a fast-forward a moment ago may now be contained (success) or divergent (conflict). The push is a single atomic ref update, so PROMOTE needs no separate atomicity argument. A dry-run check performs the identical classification and returns without pushing, reporting no output. With this the merger implements every strategy in the contract; `isConcreteStrategy` now admits all four. ## Test Plan ✅ `bazel test //runway/extension/merger/git:go_default_test` — passes (61s) New cases: fast-forward promote, promote of a commit already contained in the tip, divergent promote rejected as a conflict, a multi-commit change promoted whole to the exact named commit, an unavailable commit reported as an invalid request rather than retried, both dry-run classifications, and the two composition rules (PROMOTE with a second step, PROMOTE with a second URI) rejected as invalid requests. ## Stack 1. #459 1. #460 1. #461 1. @ #462 1. #463 1. #476 1. #477

## Summary ### Why? The merger decides which provider a change came from by its URI scheme, and rejects a scheme it has no parser for. That part works, and it happens before any git command runs. What it does not do is check that the changes in one request agree with each other. `resolveChange` determines the provider per URI and then discards it, so a request whose steps are addressed through different providers is resolved by different parsers and applied as though nothing were unusual. SubmitQueue already refuses that within a single change, but a Runway request carries one step per SubmitQueue request, so nothing covers the request as a whole. ### What? Keeps `Provider` on `changeRef` — the scheme the change was addressed through — rather than parsing it and throwing it away. `resolveAndValidate` now compares every change against the first and rejects a request that mixes providers, naming both and the steps they came from. It already walked every URI to validate it, and it runs before the mutex and before any git command, so an incoherent request costs nothing and leaves the checkout untouched. This cannot refuse a legitimate request: there is no way to address one merge through two providers, and the apply paths would otherwise have to reason about changes resolved by different parsers. Also names the change, not just the commit, in the unavailable-commit error, so the reader is not sent looking for a deleted commit when the likelier cause is a change this remote was never going to serve. Whether a change belongs to the repository this merger serves is deliberately not checked. The merger is already constrained to its checkout and remote by configuration, and a change it cannot fetch is refused on those grounds. ## Test Plan ✅ `bazel test //runway/...` — all targets pass (git suite 70s) ✅ `make lint`, `make check-tidy`, `make check-gazelle`, `make test` New cases: two steps using different providers, one change spanning two providers, and an unsupported provider — each asserted terminal and not a conflict. A multi-step multi-URI request through one provider is asserted to still succeed, guarding against over-rejecting. The rejection cases run against a Merger whose git executable does not exist, so any git invocation would fail as an exec error. Getting `ErrInvalidRequest` back proves the request was refused before the merger reached for git.

behinddwalls marked this pull request as ready for review July 30, 2026 17:36

behinddwalls requested review from a team and sbalabanov as code owners July 30, 2026 17:36

behinddwalls closed this Jul 30, 2026

behinddwalls reopened this Jul 30, 2026

behinddwalls force-pushed the preetam/runway-provider-consistency branch from f15f7d1 to d40315a Compare July 30, 2026 17:40

behinddwalls force-pushed the preetam/runway-provider-consistency branch from d40315a to 2040910 Compare July 30, 2026 18:03

behinddwalls force-pushed the preetam/runway-provider-consistency branch from 2040910 to a008f85 Compare July 30, 2026 18:08

behinddwalls commented Jul 30, 2026

View reviewed changes

behinddwalls force-pushed the preetam/runway-provider-consistency branch from a008f85 to b9c1655 Compare July 30, 2026 18:21

behinddwalls changed the title ~~feat(runway): reject changes that disagree on provider or repository~~ feat(runway): reject changes that disagree on provider Jul 30, 2026

behinddwalls force-pushed the preetam/runway-provider-consistency branch from b9c1655 to edcf03d Compare July 30, 2026 19:25

behinddwalls mentioned this pull request Jul 30, 2026

docs: define the URI as the unit of change #477

Open

behinddwalls mentioned this pull request Jul 30, 2026

ci(rebase-stack): skip native gh-stacks, re-enable for the rest #478

Merged

behinddwalls force-pushed the preetam/runway-provider-consistency branch from edcf03d to 97efb39 Compare July 30, 2026 23:38

behinddwalls force-pushed the preetam/runway-provider-consistency branch from 97efb39 to 31088f1 Compare July 31, 2026 14:32

behinddwalls force-pushed the preetam/runway-provider-consistency branch from 31088f1 to b0bbabd Compare July 31, 2026 14:34

behinddwalls force-pushed the preetam/runway-provider-consistency branch from b0bbabd to 8c121b0 Compare July 31, 2026 14:35

behinddwalls mentioned this pull request Jul 31, 2026

feat(runway): credit the change author on squash and merge commits #482

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(runway): reject changes that disagree on provider - #476

feat(runway): reject changes that disagree on provider#476
behinddwalls wants to merge 1 commit into
preetam/runway-wire-git-mergerfrom
preetam/runway-provider-consistency

behinddwalls commented Jul 30, 2026 •

edited

Loading

Uh oh!

behinddwalls Jul 30, 2026

Uh oh!

behinddwalls Jul 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

behinddwalls commented Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why?

What?

Test Plan

Issues

Stack

Uh oh!

behinddwalls Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

behinddwalls Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

behinddwalls commented Jul 30, 2026 •

edited

Loading