fix(queue): bound issue-linked re-gate fanout

[JSONbored]

Motivation

• Prevent an availability/cost issue where a single issues webhook could enqueue re-gate jobs for every open PR linked to that issue (up to the DB limit), exhausting queue, GitHub REST, and AI-review budgets.
• Reuse the existing SWEEP_MAX_PRS source budget to keep the prompt fan-out per-repo bounded while the regular stale sweep continues converging any remaining tail.

Description

• Cap the issue-side linked-PR fanout by applying .slice(0, SWEEP_MAX_PRS) to the filtered linking PRs in src/queue/processors.ts so only a bounded batch is enqueued.
• Update the surrounding comment in src/queue/processors.ts to document the availability/cost rationale and the tail-convergence behavior.
• Update the regression in test/unit/queue.test.ts to assert that a large set of linked PRs only enqueues SWEEP_MAX_PRS jobs and that staggered delays match the bounded batch semantics.

Testing

• The targeted regression test was run with npx vitest run test/unit/queue.test.ts -t "issue-side linked PR wake keeps fan-out bounded" and passed.
• Type-checking with npm run typecheck completed successfully with no TypeScript errors.
• A full run of npx vitest run test/unit/queue.test.ts failed to complete due to an unrelated RangeError: Maximum call stack size exceeded originating in the broader test harness, so the focused test above was used to validate the fix.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-07 07:57:07 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · unknown

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR bounds the issue-side linked-PR re-gate fanout in src/queue/processors.ts by slicing the filtered linkingPrs array to SWEEP_MAX_PRS before enqueuing per-PR re-gate jobs, preventing one issues webhook from enqueueing unbounded jobs across every linked open PR. The change reuses an existing budget constant already used elsewhere in the sweep logic, and the updated regression test in test/unit/queue.test.ts correctly asserts the bounded count and matching staggered delays. The fix is narrow, well-scoped, and the accompanying comment update clearly documents the availability/cost rationale and that the regular stale sweep converges any remaining tail.

Nits — 4 non-blocking

• The slice keeps whichever PRs happen first in listOpenPullRequests' return order (not oldest-linked or most-stale first), so the same subset of PRs could consistently win the fast path while others always fall back to the slower sweep convergence — consider documenting or making this ordering deliberate.
• The updated comment in src/queue/processors.ts doesn't explicitly state the numeric relationship between the bounded batch size and SWEEP_MAX_PRS for readers unfamiliar with the sweep module's budget semantics.
• Consider sorting linkingPrs by staleness or createdAt before slicing so the bounded fast path targets the PRs most likely to have a stale gate verdict, rather than an arbitrary listing order.
• If GitHub's open-PR listing order can change between calls, note whether that could cause different PRs to be woken on repeated issue-side signals, versus a stable convergence guarantee.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 343 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 343 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 51 PR(s), 343 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 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.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.66%. Comparing base (1ce4364) to head (640f184).
⚠️ Report is 15 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3960   +/-   ##
=======================================
  Coverage   93.66%   93.66%           
=======================================
  Files         372      372           
  Lines       34856    34856           
  Branches    12743    12743           
=======================================
  Hits        32649    32649           
  Misses       1588     1588           
  Partials      619      619           

Files with missing lines	Coverage Δ
src/queue/processors.ts	94.54% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.