Repository navigation
release.sh: recover conflicted release PRs with a targeted Fix run and refresh CI waits #2016
Description
This was generated by AI during triage.
Release runs for 0.28.0 (#1977) and 0.29.0 (#2010) waited for CI for hours without advancing. Both original bump commits conflicted with main in Cargo.toml and Cargo.lock, and neither had any GitHub Actions workflow runs. After later commits resolved the conflicts, the running release scripts continued polling the original SHA indefinitely.
The maintainer approved classifying this as a bug ready for an agent, and requested that the release script start a targeted thirdshift Fix run when it would help recover the release PR. The following Agent Brief specifies that recovery and its publication constraints.
Activity
JacobStephens2 commentedon Nov 11, 2026
Agent Brief
Category: bug
Summary: Recover release PRs with a bounded targeted Fix run, and stop waiting indefinitely on missing CI or superseded heads.
Current behavior:
The release command selects a green main Candidate, opens a version-bump PR, waits for workflow runs on its captured head, tags that head, waits for publication, and then merges the PR. Main can already have advanced past the selected Candidate. A version change on main can conflict with the bump, preventing GitHub from starting pull_request workflows. The workflow wait treats an empty run list as pending forever. It also never refreshes the PR head, so later repairs on the branch do not unblock the running release command.
Confirmed examples:
Desired behavior:
The release command observes its own PR while waiting and automatically starts a targeted Fix run when there is an actionable Merge conflict or completed failing CI. Use the existing Fix run and Repair loop rather than building an agent repair mechanism into the shell script. Keep attempts bounded: at most one automatic targeted Fix run per release invocation; if the result is still blocked, exit with the PR URL, cause and recovery command. Normal queued/running CI and healthy PRs start no Fix run. Missing workflows without an actionable conflict receive a bounded startup grace period, then an actionable error rather than an infinite silent wait.
A Fix run leaves the PR ready for review: explicitly override User config with --no-merge and --no-base-fix, and target this PR by URL. The release command remains responsible for tagging, publication and merging in that order. After a Fix run or external head change, fetch and validate the current PR identity and head before adopting it, refresh the summary/version diff when the release content changes, and wait for checks on the adopted head. A repaired branch must still satisfy the existing exact version-bump tree validation relative to main; extra source changes require a clear refusal for human review, with no tag pushed. Preserve existing requested Experiment coverage when a repair changes its content base.
Key interfaces:
thirdshift fix <PR URL> --no-merge --no-base-fix: reuse existing Harness/config resolution and bounded Repair behavior; use the repository's normal source invocation convention where appropriate.Acceptance criteria:
Prior art and scope:
The targeted Fix run already implements repair of an existing PR. The release workflow's missing-run and stale-head recovery are not implemented. Prior #1451 addressed a different main-movement refusal and was superseded by #1588/#1674; retain their Candidate and publication-order decisions. #1820 covers release ancestry, which must remain enforced. No relevant prior-rejection knowledge base was found.
Out of scope:
Unscoped Fix Passes, Base branch CI repair, changes to general Fix/Delivery merge policy, broad source repairs silently included in a bump-only release, bypassing trust checks, moving published tags, manually publishing 0.29.0 as part of implementing this ticket, and unrelated host-resource admission changes.