AntFleet

Disagreement · be39e8a7-anthropic-4

loadOpenPrs threshold lets first poll happen immediately but cron handler may starve outgoing-PR polls under sweep timeout

solo Opus
repo e24ef98c·PR #10·reviewed 1 week ago

Opus finding

loadOpenPrs threshold lets first poll happen immediately but cron handler may starve outgoing-PR polls under sweep timeout

lowperformancemedium
  • apps/web/app/api/cron/sweep/route.ts:19-90
  • apps/web/lib/outgoing-prs.ts:100-135
pollOutgoingPrs iterates sequentially over open rows with a synchronous GitHub call each (~300-600ms typical). The cron tick already does sweep (potentially close to 60s) + onboarder (~30s per candidate) + outgoing PRs. If outgoing_prs ever grows beyond a few dozen rows, the 180s ceiling becomes plausible to exceed and the route returns nothing. The 1-hour poll interval and the cron's hourly cadence currently limit total work, but the design has no upper bound on rows polled per tick.

Recommendation

Add a per-tick budget (e.g. limit loadOpenPrs to N=20 oldest-lastPolledAt rows) and/or run outgoing-PR polling on a separate cron route to isolate timeout risk.

Other reviewer

The other reviewer flagged nothing in this file/line range.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →

From the same review

These findings passed the unanimous gate on the same PR review. The disagreement above was filtered out; the findings below were posted.

← back to all disagreementsview public receiptssee unanimous findings + anatomies →
Tweet ↗