On a repository whose base branch has a merge queue, the native path in auto-merge-deps.yml arms an auto-merge request, exits 0, and the pull request then sits mergeable and unmerged indefinitely. It has now happened three times in netresearch/t3x-nr-llm and each one had to be bridged by hand.
Measured
|
#926 |
#933 |
#934 |
| opened |
2026-09-05 14:31Z |
2026-09-07 22:43Z |
2026-09-08 04:16Z |
| stalled for |
~7 h |
~25 h |
~19 h |
For #933 and #934 at the point of intervention:
auto_merge.enabled_by = github-actions[bot], merge_method = merge — the request this workflow armedmergeStateStatus = CLEAN, 76 checks passed, 0 failed, 0 pending, review decision APPROVED, no unresolved threadsisInMergeQueue = false, mergeQueueEntry = null, and the branch's merge queue was empty- the workflow's own runs were
completed/success — six of them across the two branches, the newest 2026-09-08 23:19Z
Recovery, in both cases: gh pr merge <n> --disable-auto, then enqueue without --auto. Both entered the queue at once (positions 1 and 2, AWAITING_CHECKS).
Reading of the cause, stated as a hypothesis rather than a finding
The base branch carries both a required_status_checks and a merge_queue ruleset, so NATIVE_GATE evaluates true and the job takes the gh pr merge --auto path at line 224 and exit 0. The armed request never turns into a queue entry. The workflow already handles the case of a stale request — it clears one before re-arming — but re-arming produces another request of the same kind, so on a merge-queue repository the clear-and-re-arm cycle cannot converge; the six successful runs above are that cycle repeating.
What is measured is the state above and that dropping the request and enqueueing directly works. Why the armed request does not enqueue is not measured here.
Suggested shape
Where the base branch has a merge_queue ruleset, skip the native path and enqueue directly, the way the gating path at line 294 already merges directly. Alternatively, verify after arming: an auto-merge request that is still pending on a PR whose gate is CLEAN is not a gate, it is a stall, and the job should not exit 0 on it.
Filed rather than fixed: the reusable workflow serves the whole org and the change wants a wider view of the callers than this one repository gives.
Assisted by claude-code:claude-opus-5 — Session
On a repository whose base branch has a merge queue, the native path in
auto-merge-deps.ymlarms an auto-merge request, exits 0, and the pull request then sits mergeable and unmerged indefinitely. It has now happened three times innetresearch/t3x-nr-llmand each one had to be bridged by hand.Measured
For #933 and #934 at the point of intervention:
auto_merge.enabled_by=github-actions[bot],merge_method=merge— the request this workflow armedmergeStateStatus=CLEAN, 76 checks passed, 0 failed, 0 pending, review decisionAPPROVED, no unresolved threadsisInMergeQueue=false,mergeQueueEntry=null, and the branch's merge queue was emptycompleted/success— six of them across the two branches, the newest 2026-09-08 23:19ZRecovery, in both cases:
gh pr merge <n> --disable-auto, then enqueue without--auto. Both entered the queue at once (positions 1 and 2,AWAITING_CHECKS).Reading of the cause, stated as a hypothesis rather than a finding
The base branch carries both a
required_status_checksand amerge_queueruleset, soNATIVE_GATEevaluates true and the job takes thegh pr merge --autopath at line 224 andexit 0. The armed request never turns into a queue entry. The workflow already handles the case of a stale request — it clears one before re-arming — but re-arming produces another request of the same kind, so on a merge-queue repository the clear-and-re-arm cycle cannot converge; the six successful runs above are that cycle repeating.What is measured is the state above and that dropping the request and enqueueing directly works. Why the armed request does not enqueue is not measured here.
Suggested shape
Where the base branch has a
merge_queueruleset, skip the native path and enqueue directly, the way the gating path at line 294 already merges directly. Alternatively, verify after arming: an auto-merge request that is still pending on a PR whose gate isCLEANis not a gate, it is a stall, and the job should not exit 0 on it.Filed rather than fixed: the reusable workflow serves the whole org and the change wants a wider view of the callers than this one repository gives.
Assisted by claude-code:claude-opus-5 — Session