🧹 Refactor fetchActivity pagination logic#367
Conversation
…rent promises Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
More reviews will be available in 48 minutes and 6 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the fetchActivity function in src/lib/github.ts to fetch GitHub event pages sequentially rather than concurrently, and adds error logging when a page fetch fails. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -697,6 +690,7 @@ export const fetchActivity = cache(async function fetchActivity( | |||
| ) { | |||
| throw error; | |||
| } | |||
| logger.error("Event fetch failed:", error); | |||
| break; | |||
| } | |||
| } | |||
There was a problem hiding this comment.
変更前のコードは3ページ分のリクエストを並行起動してから順次 await していたため、300件のイベントを持つアクティブユーザーでは3リクエストがほぼ同時に処理されていました。変更後は完全な直列実行になるため、すべてのページが100件を返す場合のレイテンシが最大3倍になります。fetchActivity は React の cache() でラップされているためリロード後は緩和されますが、初回レンダリング時にはこの差が現れます。不要なリクエストを避けるという目的自体は正しいですが、並列性を維持しつつ早期終了する別の選択肢（例: Promise.all + 結果検査）と比較検討した経緯があれば教えてください。
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/lib/github.ts
Line: 678-696
Comment:
**アクティブユーザーでの直列取得によるレイテンシ増加**
変更前のコードは3ページ分のリクエストを並行起動してから順次 `await` していたため、300件のイベントを持つアクティブユーザーでは3リクエストがほぼ同時に処理されていました。変更後は完全な直列実行になるため、すべてのページが100件を返す場合のレイテンシが最大3倍になります。`fetchActivity` は React の `cache()` でラップされているためリロード後は緩和されますが、初回レンダリング時にはこの差が現れます。不要なリクエストを避けるという目的自体は正しいですが、並列性を維持しつつ早期終了する別の選択肢（例: `Promise.all` + 結果検査）と比較検討した経緯があれば教えてください。
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
🎯 What: Replaced the concurrent promise array and mapping with a simple, sequential
forloop infetchActivity.💡 Why: By fetching paginated results sequentially, we avoid making unnecessary requests to the GitHub API if an earlier page yields fewer than 100 results or fails. This improves readability, reduces code complexity, and removes the need to maintain an unawaited promise catch array.
✅ Verification: Verified via
npx tsc --noEmitand ran the full unit test suite (npm run test), which successfully passed and retained existing behavior.✨ Result: A more maintainable, rate-limit friendly, and simpler
fetchActivityimplementation.PR created automatically by Jules for task 731492828769386556 started by @is0692vs
Greptile Summary
fetchActivity内のページネーション取得ロジックをリファクタリングし、3ページ分のPromiseを並行起動してから順次awaitする実装から、シンプルな直列forループに置き換えています。UserNotFoundError/RateLimitError以外の非致命的エラーに対してlogger.error(\"Event fetch failed:\", error)が明示的に記録されるようになりました（旧実装では Promise の.catch()サプレスハンドラ経由のみ）。awaitなPromise配列と.catch()サプレス処理が不要になり、読みやすさと保守性が向上しています。Confidence Score: 4/5
変更は限定的で、fetchActivity の内部ループ実装のみを置き換えています。エラーハンドリングの契約（UserNotFoundError/RateLimitError の再スロー）は維持されており、動作の正確性に問題はありません。
リファクタリングの意図は明確で、エラー処理の正確性も保たれています。唯一の懸念は、アクティブユーザー（300件以上のイベント）での初回レンダリング時に直列リクエストによるレイテンシ増加が生じる可能性がある点ですが、キャッシュ戦略で緩和されます。
src/lib/github.ts — 直列化による初回取得のレイテンシ特性を確認することを推奨します。
Important Files Changed
Sequence Diagram
sequenceDiagram participant C as fetchActivity (caller) participant G as GitHub API Note over C,G: 変更後（直列） C->>G: "GET events/public?page=1" G-->>C: events (≤100件) alt 100件未満 or エラー Note over C: break（page2,3はリクエストしない） else 100件 C->>G: "GET events/public?page=2" G-->>C: events (≤100件) alt 100件未満 or エラー Note over C: break（page3はリクエストしない） else 100件 C->>G: "GET events/public?page=3" G-->>C: events end end Note over C: allEvents を集計して ActivityData を返すPrompt To Fix All With AI
Reviews (1): Last reviewed commit: "Refactor fetchActivity to use sequential..." | Re-trigger Greptile