fix: bound issues-sweep cost with per-repo checkpoints and cooldown

[ionfwsrijan]

Fix: Bound Issues-Sweep Cost with Per-Repo Checkpoints and Cooldown (#860)

Problem

The issues-sweep Inngest job ran every 30 minutes and swept every install, every repo, and every issue with no caps. It re-scored every issue on each run (unbounded LLM spend), always re-read page 1 of large repos, re-scored forks whose upstream was already swept, and overlapping runs could double GitHub + LLM spend.

Changes

• src/inngest/functions/issues-sweep.ts
  • Cron reduced from 30 min to 12 h; concurrency: { key: 'issues-sweep', limit: 1 } prevents overlapping runs.
  • Hard cost caps: MAX_INSTALLS_PER_SWEEP = 50, MAX_REPOS_PER_INSTALL = 20, MAX_ISSUES_PER_INSTALL = 100, MAX_ISSUES_PER_SWEEP = 1000.
  • Per-repo sync cursor (getSyncCursor/setSyncCursor/clearSyncCursor) so a large repo is walked one page per sweep and resumes where it left off; the cursor is cleared once caught up.
  • 24 h scored_at cooldown: issues attempted within the last day are skipped rather than re-scored.
  • In-run fork→upstream dedup (seenTargets) so a fork whose upstream was already swept this run is skipped.
  • Each repo is its own step.run (a failure retries only that repo), and the rate budget is re-checked per repo so a limited install stops mid-loop.
  • Installs and repos are ordered and limited for deterministic round-robin across runs.

Impact

GitHub API and LLM spend per sweep is strictly bounded, large repos are swept incrementally, and failed repos retry without redoing the whole sweep.

Closes #860

[vercel]

@ionfwsrijan is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[ionfwsrijan]

@Soumya-codr @codersogs-code Please review this

[ionfwsrijan]

@jakharmonika364

[jakharmonika364]

Nice bounding overall - traced the budget logic through sweepRepo and it holds up, with one gap: issueBudget passed to sweepRepo is MAX_ISSUES_PER_SWEEP - totalIssuesSeen (sweep-wide remaining), not scoped to the install's remaining budget. So a repo entered late in an install's loop with little MAX_ISSUES_PER_INSTALL headroom left can still process up to ISSUES_PER_REPO_PAGE (30) issues, overshooting the per-install cap by up to 29. Suggest Math.min(MAX_ISSUES_PER_SWEEP - totalIssuesSeen, MAX_ISSUES_PER_INSTALL - issuesThisInstall) instead. Bounded/low-severity given it's capped by page size, but worth tightening given the "hard cost caps" framing.

[ionfwsrijan]

@jakharmonika364 Please review now