Observation
The merge_group handler extracts a pull request number from merge_group.head_ref with a single-segment match:
index.js:536-542 reads mergeGroup.head_ref and applies /(?:^|\/)gh-readonly-queue\/.+\/pr-(\d+)-/.index.js:555 then uses parseInt(match[1], 10) as the pull request number.
If the regex does not match at all, the handler fails closed with an unrecognized-head-ref result (index.js:543-552).
Hypothetical future shape
If GitHub ever produced a merge queue ref containing multiple pr-<n>-<sha> segments, for example for a batched group, the current regex would still match and silently take only the first pull request number. The app would evaluate that one pull request and ignore the rest, instead of treating the ref shape as unrecognized and failing closed.
This is hypothetical and currently unobserved. The current code records the evidence in index.js:586-591: 251 distinct gh-readonly-queue/* refs sampled across servo/servo, randovania/randovania, NVIDIA/cuda-quantum, home-assistant/core, and grafana/grafana each had exactly one pr-<number>-<sha> segment. GitHub currently expresses batching as a chain of single-pull-request merge groups, each based on the previous group's head, which is why merge_group.base_sha is the head commit's parent.
Suggested hardening
Before extracting the pull request number, reject refs containing more than one pr-<n>-<sha> segment. That would let the existing unrecognized-head_ref guard fail closed instead of silently narrowing the scope if GitHub changes the ref format in the future.
This is defensive hardening against a possible future GitHub behavior change, not a present defect.
Observation
The
merge_grouphandler extracts a pull request number frommerge_group.head_refwith a single-segment match:index.js:536-542readsmergeGroup.head_refand applies/(?:^|\/)gh-readonly-queue\/.+\/pr-(\d+)-/.index.js:555then usesparseInt(match[1], 10)as the pull request number.If the regex does not match at all, the handler fails closed with an unrecognized-head-ref result (
index.js:543-552).Hypothetical future shape
If GitHub ever produced a merge queue ref containing multiple
pr-<n>-<sha>segments, for example for a batched group, the current regex would still match and silently take only the first pull request number. The app would evaluate that one pull request and ignore the rest, instead of treating the ref shape as unrecognized and failing closed.This is hypothetical and currently unobserved. The current code records the evidence in
index.js:586-591: 251 distinctgh-readonly-queue/*refs sampled across servo/servo, randovania/randovania, NVIDIA/cuda-quantum, home-assistant/core, and grafana/grafana each had exactly onepr-<number>-<sha>segment. GitHub currently expresses batching as a chain of single-pull-request merge groups, each based on the previous group's head, which is whymerge_group.base_shais the head commit's parent.Suggested hardening
Before extracting the pull request number, reject refs containing more than one
pr-<n>-<sha>segment. That would let the existing unrecognized-head_refguard fail closed instead of silently narrowing the scope if GitHub changes the ref format in the future.This is defensive hardening against a possible future GitHub behavior change, not a present defect.