fix(ci): sweep PRs with unknown mergeability in pr-ci-sweeper#110945
Merged
Conversation
… target pathology Live verification showed dropped-CI PRs report mergeable=null and mergeable_state=unknown indefinitely: the stuck merge-ref computation is the same failure that dropped their CI, and close/reopen is what un-sticks it. The pending-mergeability skip therefore made the primary repair population permanently unsweepable (three real dropped PRs skipped across three consecutive sweeps). Keep skipping computed conflicts; a not-yet-computed conflict costs at most one budgeted re-fire.
steipete
marked this pull request as ready for review
July 18, 2026 20:14
openclaw-barnacle
Bot
added
scripts
clawsweeper
Bot
added
rating: 🦪 silver shellfish
Contributor
|
Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 4:18 PM ET / 20:18 UTC. Summary PR surface: Tests 0, Other -1. Total -1 across 2 files. Reproducibility: no. high-confidence after-fix reproduction is attached. The PR body gives a source-consistent production path—missing CI plus persistent unknown mergeability—but the claimed repaired behavior still needs a monitored live dispatch. Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Keep the bounded two-close budget and computed-conflict guard, then land only with a designated maintainer monitoring the first live dispatch and preserving redacted evidence that affected unknown-mergeability PRs re-fire and attach CI without disturbing auto-merge or computed-conflict PRs. Do we have a high-confidence way to reproduce the issue? No high-confidence after-fix reproduction is attached. The PR body gives a source-consistent production path—missing CI plus persistent unknown mergeability—but the claimed repaired behavior still needs a monitored live dispatch. Is this the best way to solve the issue? Yes, conditionally: reusing the existing bounded re-fire path while preserving explicit conflict and auto-merge exclusions is narrower than adding a parallel recovery system, but the safety threshold needs maintainer rollout approval. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a7e47653fc89. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Tests 0, Other -1. Total -1 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Contributor
Author
|
Merged via squash.
|
github-actions Bot
pushed a commit
to Desicool/openclaw
that referenced
this pull request
Jul 19, 2026
… target pathology (openclaw#110945) Live verification showed dropped-CI PRs report mergeable=null and mergeable_state=unknown indefinitely: the stuck merge-ref computation is the same failure that dropped their CI, and close/reopen is what un-sticks it. The pending-mergeability skip therefore made the primary repair population permanently unsweepable (three real dropped PRs skipped across three consecutive sweeps). Keep skipping computed conflicts; a not-yet-computed conflict costs at most one budgeted re-fire.
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.
What Problem This Solves
The hourly PR CI sweeper (#110889) never repaired its primary targets. Live verification found three genuinely dropped-CI PRs (#110837, #110776, #110657) skipped as
mergeability-pendingacross three consecutive sweeps: theirmergeablestaysnull/mergeable_state: "unknown"indefinitely, so the conservative guard made exactly the PRs the sweeper exists for permanently unsweepable.Why This Change Was Made
Probing showed the stuck merge-ref computation IS the pathology: repeated
pulls.getcalls over 16+ seconds never resolve mergeability for dropped-CI PRs, while healthy PRs compute within seconds. Close/reopen is what un-sticks GitHub's merge-ref machinery (validated on four maintainer PRs this week). The classify guard now re-fires on unknown mergeability and keeps skipping computed conflicts (mergeable: false); the pre-close revalidation applies the same policy. A not-yet-computed conflict costs at most one budgeted re-fire before the post-reopen recomputation yieldsfalseand skips it — bounded by the existing per-PR budget of two closes.User Impact
The sweeper actually heals dropped PR CI instead of logging skips forever. No other behavior changes.
Evidence
skip #110837/#110776/#110657 (mergeability-pending)with zero re-fires despite those heads having zero pull_request CI runs.mergeable: null,mergeable_state: "unknown"persisting across repeated GETs 16+ seconds apart for fix(ui): keep agent avatar initials on grapheme clusters #110837.node scripts/run-vitest.mjs test/scripts/pr-ci-sweeper.test.ts— 14 tests pass with the inverted null-mergeability case.