A ready-for-review Delivery re-runs full CI every time the Base branch moves, even when CI is green #906

Activity

1. JacobStephens2

   added

   bugSomething isn't workingSomething isn't working

   on Oct 20, 2026
2. JacobStephens2 commented on Oct 20, 2026

   

   JacobStephens2

   on Oct 20, 2026

   OwnerAuthor

   More actions

   This was generated by AI during triage.

   Agent Brief

   Category: bug
   Summary: With the goal of leaving the pull request ready for review, green CI on a mergeable head ends Delivery's Repair loop, even if the Base branch moved while CI ran

   Current behavior:
   In Delivery's Repair loop, when CI on the pushed head is green or absent, the loop first asks whether the Base branch moved while CI ran. If it did, it counts an upstream move, merges the Base branch in again, pushes and watches CI on the new head, whatever the goal. Only when the Base branch did not move does a ready-for-review Delivery return. A ready-for-review Delivery on a busy Base branch can spend hours re-running full CI and then fail on the upstream-move budget (5).

   Desired behavior:

   • For Goal::ReadyForReview (a Spec PR left for review, a Run that does not Self-merge): green or absent CI on the head ends the rounds, whether or not the Base branch moved while CI ran, provided the pull request is mergeable with the Base branch as GitHub reports it. The existing readiness and mergeability check after the rounds stays.
   • If GitHub reports the PR not mergeable (a conflict with the moved Base branch), behave as today: merge the Base branch in, start a conflict Repair if needed, and go round again, counting the upstream move.
   • A Base move that is not acted on is not counted against the upstream-move budget, and the Command log says so in one line, e.g. origin/main moved while CI ran; leaving the PR for review on <short head>, which merges cleanly.
   • Goal::Merged (Self-merge) is unchanged by this issue.
   • The glossary entry for the Repair loop and the comments on the loop and on the upstream-move budget say which goal goes round again on a Base move and which does not.

   Key interfaces:

   • RepairLoop::rounds and its Ci::Absent | Ci::Passed arm.
   • The Outside seam's base_branch_moved() and whatever it uses to read the PR's mergeability (the post-rounds readiness check already reads it).
   • Budgets::count_base_move and MAX_UPSTREAM_MOVES.

   Acceptance criteria:

   • An in-process Repair loop test: goal ready-for-review, CI green, Base branch moved while CI ran, PR mergeable. The loop returns that head, with no further merge, push or watch and no upstream move counted.
   • Same, but the PR is not mergeable: the loop merges the Base branch again and continues as today.
   • Goal merged, CI green, Base branch moved: behaviour unchanged (existing tests still pass).
   • The new Command log line appears in the first case.
   • cargo test, cargo clippy --all-targets -- -D warnings and cargo fmt --check pass.

   Out of scope:

   • What Self-merge does when the Base branch moves after green CI (Decide what Self-merge does when the Base branch moves after CI went green #907).
   • Re-running checks lost to runner infrastructure faults (Re-run a job that lost its runner instead of starting a CI-fix Repair #908).
   • Changing the Repair or upstream-move budgets.
3. JacobStephens2

   added

   ready-for-agentFully specified, ready for an AFK agentFully specified, ready for an AFK agent

   in-progressA Claim: thirdshift has taken this issueA Claim: thirdshift has taken this issue

   and removed

   ready-for-agentFully specified, ready for an AFK agentFully specified, ready for an AFK agent

   on Oct 20, 2026
4. JacobStephens2

   closed this as completedin #929on Oct 21, 2026
5. JacobStephens2

   removed

   in-progressA Claim: thirdshift has taken this issueA Claim: thirdshift has taken this issue

   on Oct 21, 2026