fix(issues-gh): default list page size to 200 so the swarm sees its whole backlog - #141
Open
laird wants to merge 1 commit into
Open
fix(issues-gh): default list page size to 200 so the swarm sees its whole backlog#141laird wants to merge 1 commit into
laird wants to merge 1 commit into
Conversation
…hole backlog cmd_list never passed --limit, so it inherited gh's default of 30. Every worker's fix-loop gate and the manager's monitor sweep selected work from a 30-issue window no matter how much claimable work existed. The window is also arbitrary. Once --search is in play gh goes through the search API, whose ordering is "best match" over a purely negative query (-label:"working" -label:"needs-design" ...) -- so the 30 that survive are not the newest, the oldest, or the highest priority. Callers rank P0>P1>P2>P3 after this call, which only reorders whatever the slice happened to contain. An unblocked P0 outside the page is invisible, not deprioritised, and the swarm reports IDLE_NO_WORK_AVAILABLE with real work outstanding. Measured on the repo where this surfaced: 72 claimable issues, 30 visible, 24 of the dropped ones labelled P0/P1 -- including an unblocked P0 no worker could ever claim. After the change the same call returns all 72 and that P0 is visible. An explicit --limit still wins. This covers the working and blocked buckets too, which share cmd_list: stale claim detection was capped at 30 the same way. Fixes #140
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.
Fixes #140.
cmd_listnever passed--limit, so it inherited gh's default of 30. Every worker's fix-loop gate and the manager's monitor sweep selected work from a 30-issue window no matter how much claimable work existed.The window is also arbitrary. Once
--searchis in play gh goes through the search API, whose ordering is best match over a purely negative query (-label:"working" -label:"needs-design" ...) — so the surviving 30 are not the newest, the oldest, or the highest priority. Callers rankP0>P1>P2>P3after this call, which only reorders whatever the slice happened to contain. An unblocked P0 outside the page is invisible, not deprioritised, and the swarm reportsIDLE_NO_WORK_AVAILABLEwith real work outstanding.Change
One line in
cmd_list, plus the comment explaining why 30 is not a safe default here:Applied to the canonical
plugins/autocoder/scripts/copy and propagated to the other five platform packages viascripts/package-plugin-scripts.py(no hand-editing;--checkis green).This covers the
workingandblockedbuckets too, since they sharecmd_list— stale-claim detection was capped at 30 the same way, so a swarm with more than 30 claims would have under-reported orphans.Verification
Against the live repo where this surfaced:
--limit 5still returns 5 — the default does not override callers.tests/test_issues_gh_search.sh— 15 passed / 0 failed.tests/test_script_packaging.sh— 15 passed / 0 failed.Note
blockedis absent fromBLOCKING_SEARCH, soblocked-labelled issues still come back in the open bucket and callers must re-filter. That may be deliberate, but it is a separate surprise in the same function and is not touched here.