fix(ci): sweep must retry, mergeStateStatus is computed lazily - #153
Merged
Merged
Conversation
The sweep added in #151 was a no-op. It used a single query per PR to avoid burning runner minutes, but GitHub computes mergeStateStatus lazily: the first query for a PR it has not looked at recently returns UNKNOWN and only then starts the computation. Every cold PR therefore read UNKNOWN and was skipped. The first live sweep confirmed it, skipping all 7 open PRs with 'mergeStateStatus=UNKNOWN, leaving for the next sweep'. Warms every candidate in one parallel pass, then reads the settled values, and retries on UNKNOWN rather than giving up after one attempt.
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.
The sweep added in #151 was a no-op. Caught by dispatching it rather than assuming it worked.
The defect
To avoid burning runner minutes I gave the sweep a single query per PR (
attempts = isSweep ? 1 : 6). But GitHub computesmergeStateStatuslazily: the first query for a PR it has not looked at recently returnsUNKNOWNand only then kicks off the computation. So every cold PR readUNKNOWNand was skipped.The first live sweep (run 34006340085) proves it, skipping all 7 open PRs:
Note #139 and #135-#138 are genuinely
CLEANright now, so they should have been enqueued.Fix
Warm every candidate in one parallel pass, wait once, then read the settled values, and retry on
UNKNOWNinstead of giving up after a single attempt. That is O(2N) queries rather than O(6N) sleeps, so the runner-minute concern is still addressed without breaking the mechanism.Note
This did not make things worse than before #151, and the deploy-critical path still converged (each sweep warms the cache for the next one, so it would have worked on the second pass 15 minutes later). But it was fragile and effectively halved the cadence, which is not what the fix claims to do.