Hi - we are hitting an intermittent merge queue hang. We see no checks start on any of our github actions, and we see it stuck with "10 tasks remaining" of all 10 of our required checks This is causing our entire merge queue to get stuck indefinitely, until someone noticed and manually kicks the PR out of the merge queue. Org / repo: relaytech-co/relaycode (GitHub) Examples (Graphite MQ draft PRs): - #45692 — group spec_31f547 (PR 45669), today ~15:11 UTC - #45502 — group spec_ac7a2d (PRs 45340/45341/45345/45398), yesterday Claude's analysis as to what happened: > For #45692: > - Its head SHA (a315a169) received zero GitHub Actions workflow runs — GitHub never scheduled any. Neighbouring gtmq PRs created ~60s before/after got the full ~13–22 runs. > - Because no Actions ran, ~10 of our required checks (which are posted by GitHub Actions jobs, including our "skip on gtmq_" green-status reporter) were never created. Cloud Build checks and Graphite's mergeability_check posted green independently, so the PR looks all-green while required contexts are silently missing → queue waits forever. > - The reason Actions never scheduled: the PR's base branch was deleted at the exact second the PR was created. > - #45692 created: 2026-07-23T151132Z > - Its base was another gtmq branch (gtmq_spec_4c80b7…, the head of batch PR #45691) > - #45691 closed 151126Z; its branch deleted 151132Z — same second #45692 was created. > - GitHub can't compute a pull_request test-merge commit against a base branch that's being deleted, so it never scheduled the workflow runs. The base is gone permanently, so #45692 is now stuck CONFLICTING with 0 runs > > The read: when the queue rebatches, it's deleting a base gtmq branch out from under a freshly-created child PR that's stacked on it. The top-of-batch PR (#45691, based directly on dev) was unaffected and got all its runs — only the stacked children whose base is a sibling gtmq branch are exposed to this race.