fix(queue): queue all issue-linked PR regates - #3989
Conversation
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-07 12:45:44 UTC
⏸️ Suggested Action - Manual Review
Concerns raised — review before merging
Review context
Contributor next steps
Signal definitions
🟩 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.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3989 +/- ##
=======================================
Coverage 93.58% 93.58%
=======================================
Files 382 382
Lines 35532 35533 +1
Branches 13028 13028
=======================================
+ Hits 33251 33252 +1
Misses 1618 1618
Partials 663 663
🚀 New features to boost your workflow:
|
Removing the SWEEP_MAX_PRS cap entirely reintroduced the unbounded REST-fan-out risk that constant exists to prevent (a popular/tracking issue linked from hundreds of PRs would enqueue that many staggered ~9-REST-GET re-gates from one webhook). Introduces ISSUE_WAKE_MAX_PRS: a separate, larger one-shot budget for this handler, since it fires once per issue event rather than recurring every ~2 minutes like the periodic sweep SWEEP_MAX_PRS is sized for.
aec5e56 to
56a94bf
Compare
…ue findings (#4064) The "Linked issue" review-panel signal row already recognizes hasClearNoIssueRationale(pr) and shows a passing "no-issue rationale" state when a PR body has one, but 3 separate finding-generation sites never checked it, so they kept emitting missing-linked-issue findings anyway: - buildPreflightResult's missing_linked_issue (pre-flight/planning path) - buildPullRequestMaintainerPacket's missing_linked_issue (PR-review path) - buildFocusManifestGuidance's manifest_linked_issue_required (maintainer focus-manifest policy), now accepting a caller-computed hasNoIssueRationale since this function has no PR title/body of its own Discovered live on PR #3989 (JSONbored/gittensory): its body had a valid "No issue: ..." rationale, the Linked Issue signal correctly showed it, yet the panel still counted 2 blockers and repeated "No linked issue detected" in Suggested Action.
Motivation
.slice(0, SWEEP_MAX_PRS), leaving PRs beyond the cap un-queued and susceptible to stale public gate/check state after issue label/assignment changes.No issue: found and fixed as part of a broader review-stack reliability sweep; a self-contained follow-up didn't seem worth its own tracking issue.
Description
slice(0, SWEEP_MAX_PRS)truncation inmaybeReReviewOnLinkedIssueChangeso every open PR that links the affected issue is enqueued for re-gating instead of dropping the tail (file:src/queue/processors.ts).delaySecondssend logic so the webhook does not perform expensive inline reviews (env.JOBS.sendusage retained).test/unit/queue.test.tsto seedSWEEP_MAX_PRS + 2linked PRs and assert that all linked PRs are enqueued and that no inline GitHub fetch occurs (fetchCountremains zero).Follow-up (review feedback)
The initial version of this PR removed the fan-out cap entirely, which the Gittensory review correctly flagged as reintroducing the unbounded-REST-fan-out risk
SWEEP_MAX_PRSexists to prevent (a popular/tracking issue linked from hundreds of PRs could enqueue that many staggered ~9-REST-GET re-gates from one webhook). AddedISSUE_WAKE_MAX_PRS(src/settings/agent-sweep.ts): a separate, larger one-shot budget for this handler, since it fires once per issue event rather than recurring every ~2 minutes like the periodic sweepSWEEP_MAX_PRSis sized for. A new regression test proves the cap actually bounds a large fan-out.Testing
npm run typecheck— cleannpx vitest run test/unit/queue.test.ts— 672/672 passed