You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rework the merge stage from a synchronous in-process pusher call into a
runway round-trip, mirroring the merge-conflict check. The merge
controller now builds a full runway MergeRequest from the batch's member
requests (one MergeStep per request, in Contains order) and publishes it
to the runway-owned merge queue, keyed by the batch id as the
correlation id. A new mergesignal controller consumes the MergeResult off
merge-signal, transitions the batch to Succeeded/Failed, and fans out to
conclude and speculate; a mergesignal DLQ reconciler fails the batch on
an unprocessable result.
The in-process pusher extension is retired from the orchestrator wiring
(left in-tree but unused, like mergechecker); removal is a follow-up.
workflow.md and extension-contract.md updated to reflect both the check
and the merge crossing into runway over the shared MergeRequest/
MergeResult contract.
**Outputs are unchanged except `pusher`.** This RFC moves the *input* toward identity; four of the five return contracts — conflicts, score, change info, build id/status — are exactly what they are today. `pusher` is the lone exception: because its input becomes a *list* of independently-landed batches, its result regroups per batch (`BatchID`-tagged, per-change commit detail kept underneath) so each batch's outcome stays correlatable — the "output mirrors the input unit" principle above. No other output shape changes.
43
+
**Outputs are unchanged.** This RFC moves the *input* toward identity; the four live return contracts — conflicts, score, change info, build id/status — are exactly what they are today. (The `pusher`row is not an in-process extension: merge runs out-of-process in runway, so its output is not part of this catalog — see the note below.) No other output shape changes.
44
44
45
-
The validate-time mergeability check runs **asynchronously and out-of-process** in runway rather than as an in-process extension: `validate` hands off to the `mergeconflict` controller, which publishes a full check request to the runway-owned `merge-conflict-check` queue, and `mergeconflictsignal` consumes runway's result (see [workflow.md](workflow.md)). The in-process `mergechecker`package is unused on the validate path.
45
+
The validate-time mergeability **check** and the **merge** itself both run **asynchronously and out-of-process** in runway rather than as in-process extensions, over the one shared `MergeRequest`/`MergeResult` contract — a check is a dry run of a merge. `validate` hands off directly to runway (→ `merge-conflict-check`, result back via `mergeconflictsignal`); `merge` hands the batch to runway (→ `merge`, result back via `mergesignal`) rather than calling an in-process `pusher`. See [workflow.md](workflow.md). The in-process `mergechecker`and `pusher` packages are unused on the pipeline path.
0 commit comments