Post-merge cascading rebase runs when merging from the PR page, but not via the merge-async API — intended?

[carrotRakko]

TL;DR: After a partial merge (merging only the bottom PR of a stack), the automatic cascading rebase of the remaining PRs appears to depend on how the merge was performed: merging from the PR page triggers it; calling PUT /repos/{o}/{r}/pulls/{n}/merge-async directly does not. Is this intended?

What we observed (2026-08-22, private preview, 2-3 PR test stacks, squash merge)

Setup: stack main <- PR-A <- PR-B (each PR adds a separate file, so no textual conflicts).

Case 1 — merge bottom PR via the PR page ("Only this pull request will be merged"):

• PR-A merges; ~3 seconds later PR-B's timeline shows automatic_base_change_succeeded followed by head_ref_force_pushed.
• PR-B's branch is cleanly rebased onto the squash commit (its pre-squash commits dropped, effectively git rebase --onto), diff is clean, mergeable. 👏 This matches the FAQ: "the remaining stack is automatically rebased so the next PR targets your base branch directly."
• Note: the rebase commits are attributed to the user who clicked merge, which then interacts with "require approval of the most recent reviewable push" (see also Rebase on partial merge shouldn't automatically dismiss approvals #460).

Case 2 — merge bottom PR via the merge-async API (same stack shape, merge_method=squash, poll until merged):

• PR-A merges; PR-B is retargeted to main and the merged branch is deleted — but no cascading rebase runs (head SHA unchanged, checked over several minutes).
• PR-B is left with a stale merge-base: its diff re-includes the already-merged content, and (when files textually collide) it flips to CONFLICTING.

This asymmetry seems to explain opposite reports in this forum: users merging from the UI experience automatic rebases (#458 asks to opt out, #460 reports approval dismissal), while API-driven workflows (ours is fully scripted around merge-async) never see the auto-rebase and hit the stale-base state instead.

Ask

1. Is the difference intended? If so, it would be great to document it (the FAQ currently describes the automatic rebase unconditionally).
2. Ideally: make the post-merge cascading rebase available to the API path too — e.g. an opt-in parameter on merge-async. Given Don't automatically rebase #458 asks for the opposite (opt-out on the UI path), an explicit setting covering both paths consistently would serve everyone.

Thanks for the preview — the atomic stack merge and the server-side rebase itself work beautifully; this is about making the two entry points consistent.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)