Push updated heads before retargeting PR bases in the fan-out path

The squash-merge fan-out retargeted every updated child PR onto the
target branch and only afterwards pushed the new heads, batched into a
single non-atomic push together with the merged-branch deletion. If the
push failed (e.g. someone pushed to a child mid-run, rejecting the plain
push) or a pr edit died partway through the loop, set -e aborted the run
with PRs already retargeted but their heads stale - and unlike the
conflict-resume path there is no label to re-trigger the action, so
nothing ever repaired them.

Apply the ordering the resume path already uses: push the updated heads
first, then flip the bases, and delete the merged branch last (deleting
a PR's base branch closes the PR, so every child must be off it first).
A failed push now leaves the PRs untouched on their old base.

The unit test captures the run transcript and asserts the
push -> retarget -> delete order; it fails against the previous code.
Also corrects the README: pushes are plain, not forced, and branch
deletion is its own final step.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01JHvKryT4QUpHYdNq9YEQxX

Author: claude

README.md

@@ -19,8 +19,9 @@ This action tries to fix that in a transparent way. Install it, and hopefully th
 1. Triggers when a PR is squash merged
 2. Finds PRs that were based on the merged branch (direct children only)
 3. Creates a synthetic merge commit with three parents (child tip, deleted branch tip, squash commit) to preserve history without re-introducing code
-4. Updates the direct child PRs to base on trunk now that the bottom change has landed
-5. Force-pushes updated branches and deletes the merged branch
+4. Pushes the updated branches
+5. Updates the direct child PRs to base on trunk now that the bottom change has landed
+6. Deletes the merged branch
 
 **Note:** Indirect descendants (grandchildren, etc.) are intentionally not modified. Their PR diffs remain correct because the merge-base calculation still works—the synthetic merge commit includes the original parent commit as an ancestor. When their direct parent is eventually merged, they become direct children and get updated at that point.
 

tests/test_update_pr_stack.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 
-set -e
+set -eo pipefail
 
 # Get script directory (needed for static mock files)
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
@@ -71,6 +71,8 @@ echo "Simulated Squash commit (via cherry-pick): $SQUASH_COMMIT"
 
 echo "Running update-pr-stack.sh..."
 # The update script sources command_utils.sh itself
+# Capture stdout+stderr interleaved so command ordering can be asserted.
+RUN_LOG="$TEST_REPO/update_run.log"
 run_update_pr_stack() {
   log_cmd \
     env \
@@ -79,10 +81,24 @@ run_update_pr_stack() {
     TARGET_BRANCH=main \
     GH="$SCRIPT_DIR/mock_gh.sh" \
     GIT="$SCRIPT_DIR/mock_git.sh" \
-    $SCRIPT_DIR/../update-pr-stack.sh
+    $SCRIPT_DIR/../update-pr-stack.sh 2>&1 | tee "$RUN_LOG"
 }
 run_update_pr_stack
 
+# The head must be pushed before the PR is retargeted (a failed push must leave
+# the PR untouched on its old base), and the merged branch deleted only after
+# the retarget (deleting a PR's base branch closes the PR).
+push_line=$(grep -n "git push origin feature2" "$RUN_LOG" | head -1 | cut -d: -f1 || true)
+edit_line=$(grep -n "pr edit feature2 --base main" "$RUN_LOG" | head -1 | cut -d: -f1 || true)
+delete_line=$(grep -n "git push origin :feature1" "$RUN_LOG" | head -1 | cut -d: -f1 || true)
+if [[ -n "$push_line" && -n "$edit_line" && -n "$delete_line" \
+      && "$push_line" -lt "$edit_line" && "$edit_line" -lt "$delete_line" ]]; then
+    echo "✅ Ordering: push head, then retarget base, then delete merged branch"
+else
+    echo "❌ Wrong ordering (push=$push_line edit=$edit_line delete=$delete_line)"
+    exit 1
+fi
+
 # Verify the results
 cd "$TEST_REPO"
 

update-pr-stack.sh

@@ -311,20 +311,26 @@ main() {
         fi
     done
 
-    # Only update base branches for successfully updated PRs
+    # Push the updated heads before retargeting, for the same reasons as the
+    # conflict-resume path: the head already contains TARGET_BRANCH when the
+    # base flips to it, keeping the PR mergeable (GitHub suppresses CI on a PR
+    # that conflicts with its base), and a failed push leaves the PR untouched
+    # on its old base instead of retargeted onto a stale head with nothing to
+    # re-trigger this action.
+    if [[ "${#UPDATED_TARGETS[@]}" -gt 0 ]]; then
+        log_cmd git push origin "${UPDATED_TARGETS[@]}"
+    fi
+
     for BRANCH in "${UPDATED_TARGETS[@]}"; do
         log_cmd gh pr edit "$BRANCH" --base "$TARGET_BRANCH"
     done
 
-    # Push updated branches; only delete merged branch if no conflicts
+    # Delete the merged branch last: deleting a PR's base branch closes the PR,
+    # so every child must be retargeted off it first. Keep it while conflicted
+    # PRs remain so it can be referenced during manual resolution.
     if [[ "${#CONFLICTED_TARGETS[@]}" -eq 0 ]]; then
-        # No conflicts - safe to delete merged branch
-        log_cmd git push origin ":$MERGED_BRANCH" "${UPDATED_TARGETS[@]}"
+        log_cmd git push origin ":$MERGED_BRANCH"
     else
-        # Some conflicts - keep merged branch for reference during manual resolution
-        if [[ "${#UPDATED_TARGETS[@]}" -gt 0 ]]; then
-            log_cmd git push origin "${UPDATED_TARGETS[@]}"
-        fi
         echo "⚠️ Keeping branch '$MERGED_BRANCH' - still referenced by conflicted PRs: ${CONFLICTED_TARGETS[*]}"
     fi
 }