fix(review): re-check live mergeable state before executing a conflict close - #3881
Conversation
…t close Fixes #3863. A conflict-justified heuristic close (`closeRequiresMergeableState: true`) was executed against whatever mergeable state was current when the review pass planned the action, not what's current when it actually executes. If the base branch changes between planning and actuation (Gittensory's own review latency creates exactly this window), a PR that has since become mergeable again gets closed anyway for a conflict that no longer exists. The approval-queue's staged accept-flow (agent-approval-queue.ts) already re-checks live mergeable state before honoring a conflict-justified close, but the immediate, no-approval-required execution path in agent-action-executor.ts did not — its own doc comment explicitly listed "conflict" as exempt from live re-verification. Extend the existing live-CI recheck block to also fetch live mergeable state for this one case, and deny (not merely skip) the action if the conflict has since cleared.
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Tip 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ Gittensory review result - approve/merge recommendedReview updated: 2026-07-07 02:47:36 UTC
✅ Suggested Action - Approve/Merge
Review summary Nits — 6 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3881 +/- ##
=======================================
Coverage 93.56% 93.56%
=======================================
Files 339 339
Lines 33445 33455 +10
Branches 12242 12249 +7
=======================================
+ Hits 31292 31302 +10
Misses 1528 1528
Partials 625 625
🚀 New features to boost your workflow:
|
The agent-action executor (executeAgentMaintenanceActions, executeIssueMaintenanceActions) recorded every mutation failure to audit_events only — real GitHub-mutation failures (merge/close/approve/ label/etc.) had zero Sentry visibility, unlike the equivalent "a real failure the maintainer must see" convention already used for exhausted AI-review-pass failures (captureReviewFailure in queue/processors.ts). Capture at each already-terminal point, not on every attempt: a merge held for a human (handleMergeFailure's terminal branch, after retries are exhausted or an immediately-terminal classification), and any non-merge action class, which has no retry loop so a single failure is already this pass's terminal outcome. A retryable, non-terminal merge failure stays silent, matching how a review pass that succeeds on fallback never fires captureReviewFailure either. Found while auditing the #3863 mergeable-state-recheck code path for instrumentation gaps.
…xecutes A duplicate-justified heuristic close (linkedDuplicateCount > 0) had no live recheck at all, unlike merge-conflict closes (fixed by #3881/#3863) and CI-failed closes, which both already re-verify right before the mutation. The duplicate-sibling data driving the close is reconciled ONCE at planning time (reconcileLiveDuplicateSiblings), before the often-slow AI-review/gate pass runs, and is never re-checked afterward -- if the blocking sibling PR closes or merges independently during that window, this PR still gets closed for a duplicate reason that no longer holds. The close was also immune to the close-precision circuit breaker, since hasConcreteCloseEvidence treated a duplicate link as concrete, non-judgment evidence with no staleness risk. Add closeRequiresDuplicateStillOpen + duplicateWinnerPrNumber to the planned close action, mirroring closeRequiresMergeableState's own discipline, and add a live recheck in both the immediate execution path (agent-action-executor.ts) and the staged-approval accept path (agent-approval-queue.ts): when a specific winning sibling was named, re-fetch its live state right before acting and deny the close if that PR is no longer open. When no specific winner was named (duplicate-winner election disabled, or an ambiguous election), there's no cheap single-PR signal to check, so the recheck is a no-op for that case -- same scoping precedent as the mergeable- state recheck for a non-conflict close. Left linkedDuplicateCount in hasConcreteCloseEvidence's concrete-evidence set rather than removing it: the breaker exists to catch a systematically WRONG heuristic judgment call, not to guard against an otherwise-correct deterministic fact going stale between planning and actuation -- that's exactly what the new live recheck now handles, the same relationship a base conflict already has with its own live recheck. Also fixes a second, related bug in maybePublishPrPublicSurface: the duplicate-cluster slop penalty (duplicateClusterMembership, weight 15) was computed from a raw, un-reconciled listPullRequests read, completely separate from the properly-reconciled sibling set the gate's own close decision uses -- despite a comment directly above it claiming they were the same source. If a lower-numbered sibling is closed on GitHub but its cached DB row hasn't caught up (a missed/delayed webhook), this path wrongly denied the current PR winner status and applied the duplicate slop penalty, which under slopGateMode: block becomes a real gate blocker independent of duplicatePrGateMode. Thread the same reconciled otherOpenPullRequests into this function (extending buildAuthorizedPrActionAdvisory to reconcile and return it too, for the panel-retrigger call site) instead of re-deriving a second, separately-stale answer, and correct the comment to describe what's actually happening.
…xecutes (#3930) A duplicate-justified heuristic close (linkedDuplicateCount > 0) had no live recheck at all, unlike merge-conflict closes (fixed by #3881/#3863) and CI-failed closes, which both already re-verify right before the mutation. The duplicate-sibling data driving the close is reconciled ONCE at planning time (reconcileLiveDuplicateSiblings), before the often-slow AI-review/gate pass runs, and is never re-checked afterward -- if the blocking sibling PR closes or merges independently during that window, this PR still gets closed for a duplicate reason that no longer holds. The close was also immune to the close-precision circuit breaker, since hasConcreteCloseEvidence treated a duplicate link as concrete, non-judgment evidence with no staleness risk. Add closeRequiresDuplicateStillOpen + duplicateWinnerPrNumber to the planned close action, mirroring closeRequiresMergeableState's own discipline, and add a live recheck in both the immediate execution path (agent-action-executor.ts) and the staged-approval accept path (agent-approval-queue.ts): when a specific winning sibling was named, re-fetch its live state right before acting and deny the close if that PR is no longer open. When no specific winner was named (duplicate-winner election disabled, or an ambiguous election), there's no cheap single-PR signal to check, so the recheck is a no-op for that case -- same scoping precedent as the mergeable- state recheck for a non-conflict close. Left linkedDuplicateCount in hasConcreteCloseEvidence's concrete-evidence set rather than removing it: the breaker exists to catch a systematically WRONG heuristic judgment call, not to guard against an otherwise-correct deterministic fact going stale between planning and actuation -- that's exactly what the new live recheck now handles, the same relationship a base conflict already has with its own live recheck. Also fixes a second, related bug in maybePublishPrPublicSurface: the duplicate-cluster slop penalty (duplicateClusterMembership, weight 15) was computed from a raw, un-reconciled listPullRequests read, completely separate from the properly-reconciled sibling set the gate's own close decision uses -- despite a comment directly above it claiming they were the same source. If a lower-numbered sibling is closed on GitHub but its cached DB row hasn't caught up (a missed/delayed webhook), this path wrongly denied the current PR winner status and applied the duplicate slop penalty, which under slopGateMode: block becomes a real gate blocker independent of duplicatePrGateMode. Thread the same reconciled otherOpenPullRequests into this function (extending buildAuthorizedPrActionAdvisory to reconcile and return it too, for the panel-retrigger call site) instead of re-deriving a second, separately-stale answer, and correct the comment to describe what's actually happening.
Summary
closeRequiresMergeableState: true) was executed against whatever mergeable state was current when the review pass planned the action, not what's current when it actually executes. If the base branch changes in the window between planning and actuation — and Gittensory's own review latency is exactly what creates that window — a PR that has since become mergeable again still gets closed for a conflict that no longer exists.decidePendingAgentActioninsrc/services/agent-approval-queue.ts) already re-checks live mergeable state before honoring a conflict-justified close. The immediate, no-approval-required execution path insrc/services/agent-action-executor.tsdid not — its own doc comment explicitly listed "conflict" among the close reasons exempt from any live re-verification (the fix(agent-actions): actuation freshness guard never re-verifies CI/mergeable state before merge or close #2128 CI-recheck note). That exemption was the gap Review latency can create a merge-conflict close window an author didn't cause #3863 describes.agent-action-executor.ts(previously CI-only) to also fetch livemergeable_stateviafetchLivePullRequestMergeStatefor this one case (action.closeKind === "heuristic" && action.closeRequiresMergeableState === true), running concurrently with the existing CI recheck viaPromise.all. If the live state now reads"clean", the close is denied (audited asdenied, not executed) instead of proceeding on stale planning-time data.executeAgentMaintenanceActions/executeIssueMaintenanceActionsrecorded every mutation failure toaudit_eventsonly, with zero Sentry visibility — unlike the equivalent "maintainer must see this" convention already used for AI-review-pass failures (captureReviewFailure). AddedcaptureErrorat each already-terminal point (a merge held for a human; any non-merge action failure, which has no retry loop) so a real GitHub-mutation failure is no longer invisible without a manualaudit_eventsquery.Scope
type(scope): short summaryConventional Commit format, for examplefix(api): restore profile access checks.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Validation
git diff --checknpm run typechecknpm run test:coverage— verified via lcov: all new lines/branches from both commits show non-zero hit counts; the file's only uncovered lines are pre-existing, inhandleMergeFailure's retry-exhaustion arm and an unrelated.catch(() => undefined), neither touched by this PR.npm run test:ci(full local gate, green — 538 test files / 10,733 tests passed, 2 files / 7 tests skipped)npm audit --audit-level=moderate(0 vulnerabilities)closeRequiresMergeableState: false, a persist/replay round-trip regression test, and Sentry-capture assertions on both the terminal-merge-hold and non-merge-failure paths (plus a negative-path assertion that a retryable, non-terminal merge failure stays silent). Also fixed 3 pre-existingagent-approval-queue.test.tstests whose mocks needed a second chained value now that both the approval-queue's own recheck and this new executor-level recheck call the same mocked function.Safety
UI Evidencesection. — N/A, no UI changes.