fix(backfill): summarize issues before PRs so a PR backlog can't starve the To-do surface - #23
Conversation
…ve the To-do surface runBackfill shares one per-invocation AI-call budget across PR and issue summaries, and it spent that budget PR-first. With a large PR backlog (and the frontend's 10-batch auto-loop feeding a sustained run), the assigned-issue summaries were reached last — right around where the Workers AI rate-limit wall hits "partway through" a long run — so the To-do surface's structured fields (displayTitle / next_step) were starved and never populated. Reorder so the issue loop runs before the PR loop. Issues are far fewer than PRs, so they clear in the first batch, well before the wall; PRs (Previous activity) take whatever budget remains and finish across follow-up Sync batches. No new budget knob — ordering alone fixes the starvation. Updates the backfill test that previously encoded the PR-first behavior to assert issues-first: an assigned issue is summarized even when the PR count exceeds the per-invocation budget. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
canopy | ef7d4b5 | Commit Preview URL Branch Preview URL |
Jul 07 2026, 04:58 AM |
📝 WalkthroughWalkthroughThe runBackfill function is reordered so open issues are processed and summarized before closed PRs, sharing a single AI summarization budget across both loops. Running count variables are hoisted earlier, and the test suite is updated to assert issues-first budget allocation with a matching fixture change. ChangesBackfill summarization ordering
Estimated code review effort: 2 (Simple) | ~12 minutes Sequence Diagram(s)sequenceDiagram
participant runBackfill
participant IssuesLoop
participant PRLoop
participant Summarizer
runBackfill->>IssuesLoop: process assigned issues
IssuesLoop->>Summarizer: summarize issue (within summaryBatchLimit)
Summarizer-->>IssuesLoop: summary result
IssuesLoop-->>runBackfill: summaryBudgetExhausted?
runBackfill->>PRLoop: process PRs
PRLoop->>Summarizer: summarize PR (if budget remains)
Summarizer-->>PRLoop: summary result
PRLoop-->>runBackfill: prSummarizedCount updated
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/tools/backfill.ts (1)
246-345: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffReordering logic verified correct against the new test fixture.
Traced the budget math against the updated
test/backfill.test.tsscenario (3 PRs + 1 assigned issue,summaryBatchLimit: 2): issue consumes 1 unit, 1 PR takes the remainder, exhaustion correctly triggers, and the follow-up run correctly skips the already-summarized issue while draining the rest of the PR backlog. Capture/progress application is correctly decoupled from the summarization budget gate.One observation: the issue-summarization block (Lines 264-294) and PR-summarization block (Lines 312-348) share an almost identical shape (existing-summary check → budget gate → store → pace delay), differing only in the query/table and store call. Since both loops are touched directly in this change, this could be a good moment to extract a small shared helper (e.g., taking the existing-summary query, a
storecallback, and a counter ref) to prevent the two paths from silently diverging in future edits.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/tools/backfill.ts` around lines 246 - 345, The issue is duplicated issue/PR summarization flow in backfill.ts, where the issue and PR loops now repeat the same existing-summary check, budget gate, store call, and pacing logic. Extract a small shared helper around the backfill summarization path in backfill.ts that accepts the lookup/query, store callback, and per-type counters so the issue and PR branches stay consistent and do not diverge on future edits.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/tools/backfill.ts`:
- Around line 246-345: The issue is duplicated issue/PR summarization flow in
backfill.ts, where the issue and PR loops now repeat the same existing-summary
check, budget gate, store call, and pacing logic. Extract a small shared helper
around the backfill summarization path in backfill.ts that accepts the
lookup/query, store callback, and per-type counters so the issue and PR branches
stay consistent and do not diverge on future edits.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 16e06743-9c09-42cf-8387-618685e3f0f8
📒 Files selected for processing (2)
src/tools/backfill.tstest/backfill.test.ts
1 participant
Problem
On prod, the My Work To-do cards render without their structured fields (humanized
displayTitle,next_step) — the boxes show but look half-filled. Root cause is in the backfill, not the frontend:runBackfillshares one per-invocation AI-call budget (summaryBatchLimit) across PR and issue summaries, and spent it PR-first. With a large closed-PR backlog and the frontend's 10-batch auto-loop driving a sustained run, assigned-issue summaries were reached last — right where the Workers AI rate-limit wall hits "partway through" a long run. So issue summaries were starved and their structured columns never populated.Observed on remote D1: 17 issue summaries, 0 structured (all
title/next_stepNULL); 56 of 146 PR summaries also stale — the issue queue simply never got budget.Fix
Reorder
runBackfillso the issue loop runs before the PR loop under the shared budget. Issues are far fewer than PRs, so they clear in the first batch — well before the wall. PRs (Previous activity) take whatever budget remains and finish across follow-up Sync batches. No new budget knob; ordering alone removes the starvation.Test
Rewrites the backfill test that previously encoded PR-first (
shares one AI-call budget … PRs consume it first) to assert issues-first: with 3 PRs + 1 assigned issue and a budget of 2, the issue is summarized this run rather than starved. Full suite green (408 tests), typecheck clean.Follow-up (operational, not in this PR)
Deploying this does not itself rewrite the already-stale rows — a Sync GitHub run under the deployed fix regenerates the 17 issue (+ 56 PR) summaries, issues-first, so they land structured instead of hitting the wall.
Summary by CodeRabbit
Behavior Changes
Bug Fixes