Repository navigation
fix(gitea): share and cache the /pulls scan so card refreshes can't hammer a self-hosted forge - #8858
Conversation
…ammer a self-hosted forge Each worktree card resolved its branch by paginating the repo's full /pulls listing (state=all, up to 5 pages) independently, with a 5s timeout. Gitea/Forgejo have no head-branch filter, self-hosted Forgejo takes ~5s per page (it loads reviewer data per PR), and a push event refreshes every card at once — so one repo turned into hundreds of near-simultaneous requests whose responses were aborted right as they completed, and the burst OOM-killed a 512Mi Forgejo pod (stablyai#8807). - Share one in-flight /pulls scan per repo across concurrent branch lookups and cache the result for 30s, so a burst costs a single page walk instead of one per worktree. - Raise the list-scan timeout to 15s so slow-but-successful pages are used instead of discarded and retried. - Invalidate the cached scan after Orca itself creates a PR (and before the post-create fallback lookup) so the new PR is seen immediately. Fixes stablyai#8807 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a 30-second, repository-scoped cache for paginated Gitea pull-request scans, with concurrent request de-duplication, generation-based invalidation, bounded eviction, and reset support. Branch lookup uses the shared scanner with a longer list-request timeout. Pull-request creation flows invalidate cached scans before lookup and after successful creation. Tests cover cache reset, concurrent lookups, TTL reuse, failure retries, expiry, bounded size, and stale in-flight scans. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: e6a6fbb2-f8ba-4ac2-aa68-41d847276a05
📒 Files selected for processing (4)
src/main/gitea/client.test.tssrc/main/gitea/client.tssrc/main/gitea/pull-request-creation.tssrc/main/gitea/pull-request-scan-cache.ts
…e an invalidation Review feedback: if a PR is created while a card-refresh scan is in flight, the invalidation cleared the cache but the scan then finished and re-cached the pre-create listing, hiding the new PR for a full TTL. Track a per-repo generation: invalidation bumps it (and drops the in-flight promise), and a scan only writes the cache when its generation is still current. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Fixed the invalidation race in the latest push: each repo key now carries a generation counter — |
Co-authored-by: Orca <help@stably.ai>
…ammer a self-hosted forge (stablyai#8858) * fix(gitea): share and cache the /pulls scan so card refreshes can't hammer a self-hosted forge Each worktree card resolved its branch by paginating the repo's full /pulls listing (state=all, up to 5 pages) independently, with a 5s timeout. Gitea/Forgejo have no head-branch filter, self-hosted Forgejo takes ~5s per page (it loads reviewer data per PR), and a push event refreshes every card at once — so one repo turned into hundreds of near-simultaneous requests whose responses were aborted right as they completed, and the burst OOM-killed a 512Mi Forgejo pod (stablyai#8807). - Share one in-flight /pulls scan per repo across concurrent branch lookups and cache the result for 30s, so a burst costs a single page walk instead of one per worktree. - Raise the list-scan timeout to 15s so slow-but-successful pages are used instead of discarded and retried. - Invalidate the cached scan after Orca itself creates a PR (and before the post-create fallback lookup) so the new PR is seen immediately. Fixes stablyai#8807 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gitea): don't let an in-flight scan re-cache a listing from before an invalidation Review feedback: if a PR is created while a card-refresh scan is in flight, the invalidation cleared the cache but the scan then finished and re-cached the pre-create listing, hiding the new PR for a full TTL. Track a per-repo generation: invalidation bumps it (and drops the in-flight promise), and a scan only writes the cache when its generation is still current. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gitea): bound PR scan cache and retry failures Co-authored-by: Orca <help@stably.ai> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Jinwoo-H <jinwoo0825@gmail.com> Co-authored-by: Orca <help@stably.ai>
Summary
Fixes #8807.
Each worktree card resolved its branch to a PR by independently paginating the repo's full
/pullslisting (state=all, up toMAX_PULL_REQUEST_PAGES = 5) with a 5s timeout. Gitea/Forgejo have no head-branch filter, a self-hosted Forgejo takes ~5s per page (reviewer data is loaded per PR), and a push event refreshes every card at once — one repo became hundreds of near-simultaneous requests whose responses were aborted right as they completed, and the burst OOM-killed the reporter's 512Mi Forgejo pod.Fix
pull-request-scan-cache.ts): concurrent branch lookups await the same in-flight page walk, and the result is cached for 30s. A burst that refreshes N worktree cards now costs a single page walk instead of N.findExistingPullRequestfallback), the scan is invalidated so the new PR is visible immediately rather than after the TTL.The issue's remaining suggestion (
state=openfirst with a lazystate=allfallback for merged detection) is noted as a possible follow-up; with the shared cache the marginal win is much smaller and it would double requests for merged-PR branches.Testing
vitest run src/main/gitea/— 30 tests pass;npm run typecheckclean.🤖 Generated with Claude Code