fix(fleet-bump): match the open-PR guard on the ref, not on code search - #535
Merged
Conversation
`in:head` is not a valid pull-request search qualifier. GitHub does not reject it -- it treats the query as free text, which then matches nothing. MEASURED 2026-08-21 against docudesk#711 while that PR was open: gh pr list --search "chore/fleet-shared-deps in:head" -> EMPTY (x3, ~30s apart) gh pr list --head chore/fleet-shared-deps-20260821 -> the PR gh pr list --json headRefName | startswith(...) -> the PR So the guard has never fired and could not fire. That is the worst failure available to this particular guard: it exists so the weekly sweep never opens a second PR on top of one a maintainer is already fixing, and it is the whole reason the workflow can safely refuse to force-push. Always answering "nothing open" silently withdraws that safety while looking like it is enforced. Matching on headRefName reads refs through the REST API -- no search index to lag or misparse.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
in:headis not a valid pull-request search qualifier. GitHub doesn't reject it — it treats the query as free text, which matches nothing.Measured against docudesk#711, while that PR was open
--search "chore/fleet-shared-deps in:head"(what shipped)--head chore/fleet-shared-deps-20260821--json headRefName+startswith(...)So this guard has never fired, and could not fire.
Why this one is worse than it looks
The guard exists so the weekly sweep never opens a second PR on top of one a maintainer is already fixing — and it is the reason this workflow can safely refuse to force-push. A guard that always answers "nothing open" silently withdraws that safety while still reading as enforced.
Matching on
headRefNamegoes through the REST API's ref data, so there's no search index to lag or misparse.Found while verifying #534 end-to-end: the fixed sweep opened docudesk#711 correctly (
package-lock.json+3/-3, as intended), and the guard's own query couldn't see it.