Stacks unavailable (404 from /stacks) on one repo — possibly related to a required merge queue?

[ThomasCrul]

We ran into something we can't quite explain and would appreciate a pointer. Our org is enrolled (19 of our 20 repos return 200 from /stacks), but one repo consistently returns 404, and we couldn't find a setting to change it. After a bit of digging it looks like it may be related to that repo requiring a merge queue on its base branch.

What we see

On the affected repo, both the read and the create endpoints 404:

gh api /repos/<org>/<repo>/stacks
# {"message":"Not Found","documentation_url":"...","status":"404"}

gh api -X POST /repos/<org>/<repo>/stacks --input -   # {"pull_requests":[123,124]}
# {"message":"Not Found","documentation_url":"...","status":"404"}

and the CLI reports:

$ gh stack link 123 124
Checking existing stacks...
⚠ Stacked PRs are not enabled for this repository

We tried this with a pair of freshly created throwaway PRs whose base chain we'd verified, in case something about our existing PRs was at fault. Same result each time. The same commands work fine on our other repos.

What seems to correlate

The affected repo is the only one of ours with a merge_queue rule in a ruleset (refs/heads/main). On a different repo of ours, where /stacks returns 200, we tried adding and then removing an equivalent ruleset:

Step	GET /stacks
Before	200
After adding a ruleset with {"type":"merge_queue"} on refs/heads/main	404
After deleting that ruleset	200

That flipped consistently, which is what made us think the merge queue requirement might be involved rather than an enrollment issue on our side.

Where we got confused

We spent a while looking for a repository setting to turn on, because the message says the feature isn't enabled for the repository — and from #197 we understand that wording usually points at org enrollment. One of our admins went through the repo settings and couldn't find a toggle, which left us stuck until we tried the ruleset experiment above. If the merge-queue interaction is indeed the cause, a more specific message here might save others the same detour.

We were also unsure how to square this with the docs, which describe merge queue as supported — in particular the Merge API's merge_action: default, documented as merging directly "or adds the stack to the base branch's merge queue when the branch requires one".

And we noticed #206, where merge queue and stacks do appear to coexist. If it matters, ours is a ruleset-based merge_queue rule rather than classic branch protection — happy to test anything that would help narrow it down.

What we'd love help with

• Is this expected during the preview — i.e. should we assume stacks and a required merge queue can't be combined for now?
• If so, is there anything on our side we can adjust short of dropping the merge queue requirement on that repo?

Environment: gh 2.79.0, gh-stack v0.1.0, org enrolled and working on other repos.

Thanks in advance!

[AllySummers]

I noticed exactly the same thing on one of our repos. We are on the GitHub enterprise cloud plan for our org if it matters?

I couldn't see the stack banner on my PR (that I created with Graphite) and my API requests to the stacks endpoint were 404ing.

I tried removing the merge queue requirement for our ruleset, and I immediately saw the stack banner and the API requests worked fine.

I then added back the requirement for merge queue in our ruleset, and it 404d again and I no longer see the stacks banner. I even made a stack in GitHub before re-enabling the merge queue and it's no longer visible after re-enabling the merge queue.

Happy to give more info too if it helps!

[AllySummers]

i think this is the same as #349 and #397?

[muhammad-essa-arijo]

It looks like the merge queue ruleset is the key difference here. Since removing the merge_queue rule makes /stacks return 200 again, it seems likely that required merge queues and Stacks aren't fully compatible in the current preview.

I’d also expect the API/CLI error to be more specific in this case, since the repository is enrolled and Stacks works correctly on the other repositories in the same organization.