Repository navigation
A stack child must not block its parent out of the merge queue - #671
Merged
krasnoperov-coding-agent[bot] merged 2 commits intoSep 14, 2026
Merged
Conversation
A PR whose base is another open PR's branch deadlocked both of them. The parent was admitted, found "unlanded history" shared with its child, and was evicted `policy_blocked`; the child was never admitted because its base is not the base branch. Neither could move, and nothing but a force-push to one of them would break it. The ancestry check guards a real hazard, but only in one direction. A stack child's candidate carries its parent's commits, which GitHub reviewed against the parent's branch rather than against main, so landing the child would bypass a review gate and it must wait. A parent's candidate carries only its own commits: the history it shares with the child is the parent's own, it is in the parent's diff, and it was reviewed there. Nothing is bypassed. The existing guard did cover a child that is current with its parent, through `isAncestor(parentHead, childHead)`. It misses a child that sits on an earlier parent commit — which is the ordinary state of a stack the moment the parent pushes again. Ancestry cannot recover the relationship at that point, so this reads the declared base, and `listOpenPRs` now returns it. A missing base never counts as a match, so an API that stopped returning the field would fail closed rather than disable the check in silence. The second half is getting back: `tryAdmit` refuses a head that matches the latest eviction, which is right for every class that is a fact about the head and wrong for `policy_blocked`, which is a fact about the world around it. A head evicted on environment is offered again by the startup scan and only there — a webhook saying one PR moved is no reason to re-litigate a policy decision, while a restart, which is when the policy itself can have changed, is exactly the moment to.
![review-quill[bot]](https://avatars.githubusercontent.com/u/4581825?s=60&v=4){kind=small}
krasnoperov-coding-agent
Bot
added
queue:testing
krasnoperov-coding-agent
Bot
deleted the
fix/stack-child-must-not-block-parent
branch
September 14, 2026 19:00
krasnoperov-coding-agent
Bot
removed
the
queue:merging
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
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.
Problem
MakeFX PR #164 was approved and green but Merge Steward evicted it as
policy_blockedbecause its stacked child, PR #165, shared the parent's unlanded history. The child could not enter the queue until the parent landed, creating a deadlock.Fix
policy_blockedconditions, allowing policy upgrades to recover themOutcome
Declared stacks retain parent-before-child ordering without a child blocking its own parent. Unrelated shared unlanded history remains blocked, and head-local failures still require a new push.