feat(miner): make queue next WIP-cap-aware via --global-wip/--per-repo-wip - #5600
Merged
Conversation
…o-wip queue next always called the naive, uncapped dequeueNext() directly, even though a WIP-cap-aware batch claimer (portfolio-queue-manager.js, used by queue claim-batch) already existed. Adds --global-wip/--per-repo-wip flags to queue next, mirroring claim-batch's own flag names. Both flags are omitted (unset/uncapped) by default, so every existing caller's behavior is byte-identical to before -- queue next only becomes cap-aware when an operator explicitly opts in, matching the "off by default" convention used elsewhere in this package (ledger retention, dry-run). When set, a new selectNextEligibleTarget() picks at most one atomically-claimable target via the store's existing batchClaim transaction, refusing to claim once the global or the target row's own per-repo in-progress count has reached its cap -- never claiming and then discarding extra rows, and never reusing the engine's diversifying batch-selection algorithm (that stays claim-batch's job). Scope note: the issue's ".gittensory-miner.yml" cap-source suggestion isn't wired here -- that file is resolved from an ALREADY-CLONED repo on disk (miner-goal-spec.js's resolveMinerGoalSpec), but queue next dequeues BEFORE any worktree is prepared for the claimed item, so no local copy of the target repo's yml exists yet at that point. Reading it would require new live-fetch plumbing this issue doesn't otherwise need. CLI flags (matching claim-batch's existing, established convention) deliver the same acceptance criterion -- "setting a WIP cap ... stops queue next from claiming once the cap is reached" -- without that new dependency. Advances #4850.
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
loopover-ui | 570b600 | Commit Preview URL Branch Preview URL |
Jul 13 2026, 08:25 AM |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5600 +/- ##
==========================================
- Coverage 95.02% 95.00% -0.03%
==========================================
Files 573 573
Lines 45564 45600 +36
Branches 14661 14661
==========================================
+ Hits 43296 43321 +25
- Misses 1517 1528 +11
Partials 751 751
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
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.
Summary
queue nextalways called the naive, uncappeddequeueNext()directly, even though a WIP-cap-aware batch claimer (portfolio-queue-manager.js, used byqueue claim-batch) already existed and was built/tested.--global-wip/--per-repo-wipflags toqueue next, mirroringclaim-batch's own flag names.queue nextonly becomes cap-aware when an operator explicitly opts in, matching the "off by default" convention used elsewhere in this package (ledger retention, dry-run).selectNextEligibleTarget()picks at most one atomically-claimable target via the store's existingbatchClaimtransaction — refuses to claim once the global or the target row's own per-repo in-progress count has reached its cap. Never claims-then-discards extra rows, and doesn't reuse the engine's diversifying batch-selection algorithm (that staysclaim-batch's job —queue nextkeeps its existing single-highest-priority-item contract).Scope note: the issue's
.gittensory-miner.ymlcap-source suggestion isn't wired here — that file is resolved from an already-cloned repo on disk (miner-goal-spec.js'sresolveMinerGoalSpec), butqueue nextdequeues before any worktree is prepared for the claimed item, so no local copy of the target repo's yml exists yet at that point. Reading it live would require new remote-fetch plumbing this issue doesn't otherwise need. CLI flags (matchingclaim-batch's existing, established convention) deliver the actual acceptance criterion — "setting a WIP cap ... stopsqueue nextfrom claiming once the cap is reached" — without that new dependency.Closes #4850
Test plan
selectNextEligibleTarget()unit tests: null-caps replicates pre-Wire WIP-cap-aware batch claiming into the real CLI path #4850 behavior, empty queue, global-cap-reached refusal, per-repo-cap-reached refusal (and that a different repo's row is still eligible)runQueueNextintegration tests: caps enforced end-to-end, unset caps stay byte-identical to old behavior, only---per-repo-wip-set leaves global genuinely uncapped,--dry-runreports the requested capsnpx vitest run test/unit/miner-*.test.ts— 1667/1667 passingnpx tsc --noEmitcleannpm run build:minercleannpm run command-reference:check— unaffected (miner CLI isn't in that generator's scope)