fix(gate): do not lift the manual-review hold while another hold is live - #9943
Merged
Conversation
Contributor
|
Important 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏳ LoopOver is waiting…LoopOver has seen this pull request and is waiting on CI checks to finish before reviewing it. This comment will update once the review runs. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed · 🟨 Waiting |
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
#9942 added the release guarded on `manualHoldReason === null`, and stated that no add site could be live at that point. That ternary covers only the guardrail hit, unverified CI, an action_required conclusion and a not-review-good verdict. Every would-MERGE hold -- migration collision, unlinked-issue match, priority eligibility, unlinked-issue close, unstable merge state -- fires on `reviewGood` with a SUCCESS conclusion, which is precisely when manualHoldReason is null. So the release stripped the label while the hold was still standing, and that label is exactly what the executor checks to deny merge and approve: removing it removes the enforcement for a hold nothing has resolved. Verified against the merged planner before changing it -- all five holds planned a removal. The condition is now one named predicate listing every reason that would ADD the label, so a hold added later cannot silently fail to suppress the release. The counterweight is tested too: with nothing holding, the label is still released, so the one-way latch #9942 fixed does not come back.
JSONbored
force-pushed
the
fix/manual-review-latch-9939
branch
from
July 30, 2026 19:26
641a57b to
f1e1e42
Compare
Owner
Author
|
Validation complete on the final tree:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9943 +/- ##
==========================================
- Coverage 91.88% 91.00% -0.88%
==========================================
Files 928 928
Lines 113670 113671 +1
Branches 27411 27412 +1
==========================================
- Hits 104440 103449 -991
- Misses 7931 9118 +1187
+ Partials 1299 1104 -195
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
Follow-up to #9942, which landed the #9939 fix while this was in flight. This PR no longer duplicates it — it was reset onto
mainand now fixes one gap in the released version.The gap
#9942 guards the release on
manualHoldReason === null, and its comment states the case cannot arise:manualHoldReasoncovers only the guardrail hit, unverified CI, anaction_requiredconclusion, and a not-review-good verdict. Every would-MERGE hold fires onreviewGoodwith asuccessconclusion — precisely whenmanualHoldReasonis null.Verified against the merged planner, before changing anything
Driving
planAgentMaintenanceActionsfrommain(35fceed) with the label present, provenance set, and one hold live:migrationCollisionHoldunlinkedIssueMatchHoldpriorityEligibilityHoldunlinkedIssueMatchCloseIt is removed once and not re-added on the next pass (with
review_state_labelacting, the re-add sites are skipped in favour of the sibling disposition label). So this is not a flap — it is a one-way strip.Why that matters: the manual-review label is the exact thing the executor checks to deny
mergeandapprove. Removing it while the hold still stands removes the enforcement for a hold nothing has resolved. Whether a merge actually follows depends on the rest of the plan — I am not claiming these PRs merged — but the block that was supposed to stop them is gone.The fix
One named predicate listing every reason that would ADD the label, so a hold added later cannot silently fail to suppress the release:
Everything else in #9942 is untouched — the provenance column, the SHA-agnostic release, the human-applied-label refusal.
Validation
manualHoldReason === nullfails exactly those 5 and leaves the counterweight passing, so they are pinning the real behaviour and the guard is not merely over-broad.test/unit/agent-actions.test.ts: 343 passing.