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!