Why does our Merge Queue get stuck?

[magnattic]

We enabled Merge Queue Beta and really love the idea, since this would solve many problems we have.

For some reason the MQ seems to get stuck on some PRs and simply does not merge them, even though

• all checks have passed on the readonly branch
• the PR is on the top of the queue

Readding them or jumping the queue does nothing. The problem persists.

Is there anything we could check to figure out what is going on?

[antonagestam]

@magnattic I'm experiencing the same issue, I suspect it might be due to the fact we didn't update our CI job to run on gh-readonly-queue/... branches as suggested here. I'll give that a try and see if it works. It would be nice if that's mentioned and linked to in the UI when enabling merge queues.

[antonagestam]

@magnattic I can confirm this was the issue, after altering our workflow to include a trigger for gh-readonly-queue/{base_branch}/** it works as expected.

[magnattic]

How exactly did you set it up?

• Our checks are not limited to certain branches, they already run on the gh-readonly-queue/ branches. Example trigger:
  
• This is our branch protection config, as you can see we don't require any special check, only an up to date branch:
  
• The MQ works for some PRs, but on some it simply gets stuck for no visible reason (which blocks the whole queue then)

[antonagestam]

Ah, I guess your issue isn't related to this then, the symptoms just seemed similar.

This is our config, dev is our trunk/default branch:

on:
  push:
    branches:
      - gh-readonly-queue/dev/**
  pull_request:

[orestesgaolin]

that fixed it for us as well!

[magnattic]

Quick update: Github has confirmed the issue to us via mail and they are working on a fix.
For anyone else facing this, this is their current suggestion for a "workaround" for now:

• try to remove the head of the queue
• if that doesn't work, clear the queue
• if that doesn't work, disable then reenable the queue

[danjamespearce]

@magnattic we were witnessing the same issue. For us, it turned out to not be an issue with the branch protection rule on main, but with a catch-all "/" branch protection rule. We're still investigating why this was the case - as this catch-all rule does nothing apart from check for signed commits.

[lukaspiatkowski]

This happened to our Merge Queue as well, repro for us was:
Merge 1st PR with a Merge Queue, then try to merge 2nd one while the 1st is still running. The 2nd will never be merged or removed from the Merge Queue regardless of CI result.

It was still working yesterday (we have been running Merge Queue for a while now). It is sad there is still no insight into the Merge Queue. I have created a support ticket, but I couldn't provide any logs... I will let you know here if the issue got resolved via support.

[danlucraft]

This is happening to us too now, and it's been blocked for at least 9 hours.

Looking at suggestions discussed above:

• it's not a branch protection rule, because we don't have any except the master one with the MQ
• CI is set to run on all branches (except master)

I'm going to follow the procedure suggested because we have to get it un-blocked:

• try to remove the head of the queue
• if that doesn't work, clear the queue
• if that doesn't work, disable then reenable the queue

And we'll see what happens.

[danlucraft]

Follow up:

Trying to remove the head of the queue gave this error message

Clearing the queue has cleared it, and I've been through the PRs and disabled auto merge then re-enabled auto merge

[magnattic]

So the Merge Queue seems to work for us now. The issue was that we had no required status checks set. After setting one, it started to work.

It's really unfortunate that GH does not support only requiring checks that were actually triggered. If a workflow is path-dependent it cannot be set as required or it will get stuck. And if you don't set it as required, the merge queue will never wait for it to pass before merging.
We are now using https://github.com/upsidr/merge-gatekeeper to work around the problem, but this really should work out of the box.

[sweepy84]

We gave up on using this. We need to be able to see what the queue is doing along with errors etc. otherwise too hard to debug for us atm.

[AllDmeat]

Hello,
I hope you can help me with an issue that we have been experiencing with our GitHub Actions workflow.

We have recently enabled branch protection rules and merge queue, and everything was working fine while we had only one required run check: unit tests.
Yesterday we enabled one more required check — sonar. Both checks are sequenced so that unit tests run first, and then sonar only runs after completing the unit tests.

While it works fine during the pull request stage, sonar fails to start in merge queue. However, the unit tests run without any issues.
Here are some excerpts from our workflow files:

unit_tests.yml

name: Unit Tests

on:
  pull_request:
    branches:
      - 'develop'
      - 'master'
      - 'release/**'
      - 'hotfix/**'
  merge_group:
  workflow_dispatch:

...

jobs:
  unit-tests:
    ...

  call-sonar:
    needs: unit-tests
    if: ${{ always() }}
    uses: ./.github/workflows/sonar.yml
    with:
      artifact-name: ${{ needs.unit-tests.outputs.xcresult-artifact-name }}
    secrets:
      ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
      github-token: ${{ secrets.GITHUB_TOKEN }}
      sonar-token: ${{ secrets.SONAR_TOKEN }}

sonar.yml

name: Sonar

on:
  workflow_dispatch:
  workflow_call:
    inputs:
      artifact-name:
        required: true
        type: string
    secrets:
      github-token:
        required: true
      sonar-token:
        required: true
      ssh-private-key:
        required: true

The Sonar workflow is not starting, and we can only see "Starting job..." in the logs.

Are we missing something?

Thank you for your help in resolving this issue.

[timherby]

We hit this again today, and it's clearly the dropped-dispatch variant, not a config issue — our workflows are correctly triggered on merge_group and sibling groups in the same queue dispatched fine.

Stuck merge-group commit 9e758432:

check-suites → 6 suites, all GitHub Apps, zero github-actions
actions/runs?head_sha=9e758432 → total_count: 0

So the required merge-queue checks were never produced and the head entry hung in AWAITING_CHECKS, blocking ~23 PRs. It happened right after a queue re-form (a jump). The "remove the queue head" workaround worked — dequeue + re-enqueue the head forced GitHub to rebuild the group and dispatch CI.

Would love (a) a fix for the dropped dispatch and (b) any queue visibility into "group formed, no CI dispatched" — right now it's invisible until a human notices the queue isn't moving.