LLVM PR merges fail as GitHub hits 10-second timeouts

LLVM developers have spent days unable to land approved pull requests through GitHub’s ordinary Merge button, hitting opaque failures, half-applied merges, and occasional empty duplicate commits on main.

Tom Stellard flagged the project-wide pattern after multiple maintainers saw the same symptoms: “Unable to read response from the server,” “Merge already in progress,” or rule-violation errors after clicking Merge. Retrying quickly appears to make things worse. The gh CLI is no clean escape either; it has returned GraphQL 503s and “merge in process” errors while still pushing the commit to main and leaving the pull request open and unassociated.

GitHub’s engineering team traced the root cause. Manual merges sometimes exceed a ten-second web request timeout while waiting on back-end work. The worker is then terminated before it can return a response or mark the merge complete, so the operation stays active and later attempts collide with it. Auto-merge avoids the trap because the real merge runs in a background job outside that timeout.

The practical recipe is awkward. Once CI has passed, the auto-merge control disappears, so maintainers must first refresh the branch with a merge or rebase (which requeues CI and loads the runners again), then re-enable auto-merge. Some have had more luck with a force-push followed by squash auto-merge, or with repeated REST API merge calls that poll until the commit actually appears on main. Contributors without commit access are left coordinating extra steps, and individual pull requests have sat unmerged for days.

Support tickets remain open. The episode has nonetheless renewed broader unease that GitHub’s core review and merge path is growing less reliable for a repository of LLVM’s size and traffic.