Skip to main content

v2.61.0

Released 2026-09-22. One minor release, two changes, both about a build surviving the network.

Binaries and the merged-pull-request list are on the GitHub releases page.

A coordination verb that failed in transit is asked again​

A product's CI lane claims its job over the network, and one reset connection on that claim ended the lane before a step had run:

✕ claiming job integrations-worker.dev.verify-deploy: Post "…/jobs/…:claim":
  read tcp 10.1.0.194:44618->104.21.44.152:443: read: connection reset by peer

That was a failure with nothing wrong in the product, and it failed the phase's landing and stopped an unattended build. The remote-state client had retried transient errors for years; the coordination client — the claim, the heartbeat, the completion, the frontier and the log — did not.

It does now. Every coordination verb is safe to ask twice, because the server makes each one idempotent by construction: a re-claim by the holder of a live lease answers the same lease, a heartbeat renews what it renews, a complete for a job already in that terminal state is a no-op, and the rest are reads. So a transport failure (reset, timeout, EOF) and a 429 or 5xx are retried with exponential backoff and jitter, honouring a Retry-After hint, five attempts in all. A 4xx is an answer and is never retried — a 409 on a complete still means the lease was lost — and the caller's own context ending is the caller giving up.

orun pr land re-runs a failed lane before it refuses​

The convergence watch after a merge has always resumed failed lanes (orun.run/watch@v1, resumeBudget). The landing before it refused on the first red check. Now a landing with a rerunBudget (default 2, on the action and as --rerun-budget on the command) asks GitHub to re-run the failed jobs of the head's workflow runs, starts its wait over with a fresh timeout, and refuses only when a failure outlasts the budget — counted in the refusal:

provenance: checks failed on abc1234 after 2 re-run(s): workflow CI (failure)

The moment after a re-run is issued, GitHub still answers with the previous attempt; the landing waits for a workflow run to report a later attempt before it reads the head again, so a re-run is never mistaken for its own failure and the budget is never spent twice on one attempt. A re-run GitHub refuses — a token without actions: write — leaves the failure reported as it was. 0 keeps the old behaviour. The action reports reruns beside merged and mergeSha.

The product's own CI, as the baselines write it, passes --retry to orun run on a re-run attempt, so the re-run lane re-opens its job rather than reading a terminal failure — which is what makes a GitHub re-run a true resume.