Hey all! Our team has recently been seeing a higher rate of PRs being kicked out of the merge queue due to "merge conflicts." Despite this message, we observe that the PRs don't actually show any merge conflicts and are immediately eligible to be added back to the merge queue afterwards. For example, one PR's log looked like this:

Jul 14, 2:41 AM UTC: rowantran added this pull request to the Graphite merge queue.
Jul 14, 2:44 AM UTC: The Graphite merge queue couldn't merge this PR because it had merge conflicts.
Jul 14, 2:48 AM UTC: rowantran added this pull request to the Graphite merge queue.
Jul 14, 2:50 AM UTC: The Graphite merge queue couldn't merge this PR because it had merge conflicts.
Jul 14, 2:54 AM UTC: rowantran added this pull request to the Graphite merge queue.
Jul 14, 2:56 AM UTC: CI is running for this pull request on a draft pull request (#9131) due to your merge queue CI optimization settings.
Jul 14, 3:01 AM UTC: Merged by the Graphite merge queue via draft PR: #9131.

and we didn't publish any new revisions to the PR between subsequent attempts to merge. Potentially relevant info: • Link to the Graphite PR (it's in a private repo but would be happy to share more details over DM if it helps troubleshoot): app.graphite.com/github/…/9110 • We're using squash & merge as our merge strategy, with fast-forward merge enabled and CI set to run on topmost PR of every stack, 4 stacks at a time. We're currently suspecting this is a Graphite-side bug due to the lack of actual merge conflict as far as we can tell. Would really appreciate any pointers to what might be causing this! We've been very happy campers with Graphite so far, but this issue has been a bit frustrating 😓

I've had this as well, a PR saying this over and over again and no indication as to why, frustrating!

Thanks Rowan! Looked at the logs for #9110. The bounce was our speculative merge rebasing the stack (#9110–#9112) onto the queue tip; that rebase hit a conflict (even when GitHub still looked clean vs main), which matches the eject → requeue → later success pattern. Digging into why that mis-fired. Any more stacks bouncing the same way since?

Appreciate it Chris. I haven't personally seen the same issue since, but I did see the following on app.graphite.com/github/…/9154:

Jul 14, 5:39 PM UTC: rowantran added this pull request to the Graphite merge queue.
Jul 14, 5:59 PM UTC: The Graphite merge queue couldn't merge this PR because it failed for an unknown reason (An unexpected error occurred when attempting to merge. Please try again or contact Graphite support if this continues.).

Thanks for this! This was a bit different symptoms, it does appear to be a bug with how we are handling the LFS. For LFS-normalized files, that local tree can appear dirty, and Graphite does not reset/discard/clean before switching branches, so git aborts. We have an existing bug report for this I have added you to, but no ETA on a fix right now. For a workaround please complete the merge in GitHub.

This is happening to my team pretty consistently now, but we don't use LFS AFAIK. app.graphite.com/github/…/…#…

RE: roboscreener PR (#11565): It merged successfully, nothing was lost or stuck. The repeated "failed to fast-forward merge" entries were GitHub holding the PR as blocked while its required Typecheck status check was still running; Graphite automatically retried and the merge went through the moment Typecheck finished (around 10:56 AM PT). No action is needed on your end.

I had to add it to the merge queue multiple times, but yes on the last one it went through

Let me do a deep dive and check back in, might be tomorrow AM. Want to make sure I am looking at all causes, but from my initial scan it does appear to be related to the Typecheck status. However let me cross my t's and dot my i's and get back to you asap.

We've had that status check for a very long time, FWIW. It did previously prevent us from clicking the Merge button (which makes sense), but now it doesn't. Maybe that's the issue? some button state mgmt issue?

The root issue is we were trying to continue as normal because we didn't see that status check as a blocker and when attempting any actions we were met with the following response from GitHub: Required status check \"Typecheck\" is in progress. - https://docs.github.com/articles/about-protected-branches I'll try and see if anything changed recently that may have caused it.

Hey Chris! Here's another stack that seems to have had the same "merge conflicts" issue as the one originally reported in this thread: app.graphite.com/github/…/9402 Let me know if you're able to dig into the root cause, or if there's any other info we can provide on our end to help debug.

Hey There, this one did indeed go thru and I think it was delayed due to the GitHub outage and then us working thru the backfill. Are you still seeing issues today?

The root issue is we were trying to continue as normal because we didn't see that status check as a blocker and when attempting any actions we were met with the following response from GitHub: Required status check \"Typecheck\" is in progress. - docs.github.com/articles/about-protected-branches

I presume then that this is causing the merge button to be enabled when it shouldn't be? or was there a shift to allow a PR to enter the merge queue w/ required status checks incomplete, and its just timing out now?

Hey There! #​9402 never timed out. It took about 3 hours because its stack hit a real git rebase conflict that failed each merge attempt until the conflicting change cleared; the next attempt rebased cleanly and merged at 12:48 AM PT. So raising the merge-queue timeout wouldn't have helped as there was no timeout, and a longer one won't resolve a rebase conflict. One thing worth fixing on your end: Graphite's GitHub App on your org is currently missing read access to checks/statuses (it's been returning "Resource not accessible by integration" since around July 10), which limits Graphite's ability to read live check state. Re-granting the Graphite App's permissions on the Isara org would clear that up. GitHub's own branch protection still independently enforces required checks at merge, so this didn't let anything merge that shouldn't have

Thanks for the update on #9402 Chris 🙂 After re-pulling the PR stack and restacking manually we did indeed see that it went through successfully. The weird part then is just that Graphite's UI didn't show that there was a merge conflict.

GitHub only shows that accept prompt when there's a pending permission update from us. On that installations page, click Configure next to Graphite (needs an org owner). Look for a yellow "Review request" banner at the top. Does this not appear?

Oh yeah - sorry for not making that clear. The "installation link" I was referring to was the one for Graphite's app installation specifically, and we just see the normal page with no banner:

Can you check this for me? Graphite App installation (github.com/organizations/Isara-Laboratories/settings/installations > Graphite) shows Pull requests: Read + Checks: Read (and Commit statuses)

yep! (I believe the image above has the info you need)

Sweet let me do a smoke test few moments