Hey there, Since Monday (Sep 7) "Merge N PRs" no l...
# report-bugs
a
Hey there, Since Monday (Sep 7) "Merge N PRs" no longer merges a whole stack for us. It merges the bottom PR, rebases the next one, then gives up on it in the same minute. The same kind of stack merged fully automatically on Sep 2 and Sep 4, with no change on our side (no merge queue, plain stack merge from the app). Timeline from Graphite's own "Merge activity" comment on PR #3839 in Tabflows/platform-v2 (UTC): - 21:52 "A user started a stack merge that includes this pull request" - 215305 bottom PR #3838 merged - 215334 Graphite rebased #3839 onto main (base retargeted via graphite-base/3839 -> main) - 21:54 "Graphite rebased this pull request as part of a merge" and, same minute, "Graphite couldn't merge this PR because it was not satisfying all requirements" - 215552 CI on the rebased commit finished green, GitHub reports the PR as CLEAN - 215954 the "Graphite / mergeability_check" run appears on the new commit (on Sep 4 it appeared 10 seconds after the rebase) All upstack PRs then get "couldn't merge this pull request because a downstack PR #3839 failed to merge". Same pattern on #3780, #3781 and #3785 earlier that day. For comparison, on Sep 4 (#3765 to #3767) the comment reads "rebased this pull request as part of a merge" and five minutes later "merged this pull request with Graphite", i.e. the job waited for CI, as your docs describe ("If the base PR in the stack has pending GitHub checks, do nothing"). So the merge job now seems to evaluate requirements once, right after its own rebase while the new commit's checks are still pending, and cancels instead of re-polling. In the dashboard the rebased PR shows "needs restack" for a few minutes, then becomes mergeable and I can click merge again. "Merge when ready" does not help. gt sync && gt restack && gt submit does not help either, the remote branch is already rebased. Break window: between Sep 4 20:02 UTC (last fully automatic stack merge) and Sep 7 20:14 UTC (first failure). Repo settings, unchanged since June: rulesets only, "Require branches to be up to date" off, "Dismiss stale approvals" off, 1 approval, squash only, required checks Prettier/Build/Lint/Typecheck/Test on GitHub Actions. gt 1.8.5. Is anyone else seeing this?
c
This matches the stack merge stopping on the rebased PR instead of waiting for that commit’s checks, like it did on Sep 4. That’s not the intended behavior. Once the rebased PR is green and no longer “needs restack,” merging from there should continue the stack. Merge when ready won’t resume the cancelled job.
a
Interesting! My temporary fix for this was to start the merge, then one failed, and then I started it again with admin overrides and it worked.
c
We are investigating what seems to be a bit of a delay on GitHubs side, no ETA but I think its related to this.
a
ok thanks for being on top of this! 🙏
🙌 1