Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions api/runway/messagequeue/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,8 @@ One message serves a queue pair because a merge-conflict check is a dry run of a

`MergeResult.outcome` is an `Outcome` enum (`OUTCOME_UNSPECIFIED`/`SUCCEEDED`/`FAILED`): `SUCCEEDED` means mergeable (check) or merged (commit), `FAILED` a conflict or a failed apply; `reason` carries the explanation when `FAILED`. Per-step detail is in `steps` (request order): each `StepResult.outputs` is the list of `StepOutput`s the step produced on the merge target, **in application order** (the order they were created). A committing merge populates `outputs`; a dry-run check, an already-present change, or a failed step leaves them empty. `StepOutput.id` is the VCS-neutral revision identifier (git SHA, Mercurial hash, Subversion revision, Perforce changelist, …), with room to grow (author, timestamp, …).

A committing merge is all-or-nothing against the merge target: Runway updates the target at most once per request, and a `SUCCEEDED` result means every step in `steps` is reachable from the target, while a `FAILED` result means the target is unchanged.

## Evolution

Contract changes are additive-only: add new fields; never remove, rename, repurpose, or retype an existing field, and never reuse a field number. protojson ignores unknown fields on read and omits zero-valued fields on write, so a new optional field is backward-compatible in both directions.
2 changes: 2 additions & 0 deletions doc/rfc/runway/workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,8 @@ Together these guarantee the client's correlation id always resolves: the primar

Runway has no persistent state — no request store, no job store, no database. Idempotency is achieved through the VCS contract: merge detects already-pushed changes (revisions reachable from HEAD) and treats them as already-landed. Merge-conflict check is read-only and naturally idempotent.

A committing merge is also atomic against the merge target: it updates the target at most once per request, and afterwards either every step of the request is reachable from the target or the target is unchanged. A retried redelivery therefore either replays cleanly against the same unchanged target or finds its work already landed.

## Ownership by service

### Runway
Expand Down
3 changes: 3 additions & 0 deletions runway/extension/merger/merger.go
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,9 @@ type Merger interface {
CheckMergeability(ctx context.Context, req *runwaymq.MergeRequest) (*runwaymq.MergeResult, error)
// Merge applies the ordered steps, commits the result to the remote, and
// reports per-step Outputs (the VCS-neutral revision identifiers produced).
// Merge is all-or-nothing against the target: it updates the target at
// most once per request, and afterwards either every step is reachable
// from the target or the target is unchanged.
Merge(ctx context.Context, req *runwaymq.MergeRequest) (*runwaymq.MergeResult, error)
}

Expand Down
Loading