Feature/refresh#590
Conversation
|
Warning Review limit reached
More reviews will be available in 22 minutes and 52 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ 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 |
❌ Deploy Preview for github-spy failed.
|
|
3 succesful changes was made .Please accept my PR |
PR Title
Fix ActivityFeed polling to prevent GitHub API rate limit exhaustion
Summary
Closes: #475
Refactored ActivityFeed.tsx to use sustainable polling intervals and defensive state management, preventing unauthenticated GitHub API rate limit exhaustion and UI flicker during background refreshes.
Architecture Context
Public REST APIs protect their infrastructure by imposing strict request limits based on a client’s IP address. The unauthenticated GitHub API rate limit is capped at 60 requests per hour.
Failure Mechanism
Original ActivityFeed used a rapid 30‑second polling (setInterval(fetchEvents, 30000)).
Every background refresh cycle explicitly called setLoading(true).
Impact
Leaving the dashboard open for ~30 minutes exhausted the 60 unauthenticated requests, causing 403 Forbidden errors across the app.
Aggressive loading states caused constant UI flicker during polling.
Solution
Extended background polling interval from 30s → 120s (setInterval(() => fetchEvents(true), 120000)).
Added isMounted guard to prevent state updates after unmount.
Introduced hasLoadedOnce flag to suppress loading state during background refreshes.
Kept initial load showing loading, but background refreshes now happen quietly without interrupting the user.
Why
Prevents early rate limit depletion.
Stops aggressive UI flicker during background polling.
Makes refresh behavior safe during tab transitions/unmounts.
How to Test
Open the dashboard and leave it running for >30 minutes.
Verify that API requests remain under the 60/hour unauthenticated limit.
Confirm that background refreshes occur every 120s without UI flicker.
Switch tabs or unmount the component → no state update errors.
Acceptance Criteria
No 403 errors due to rate limit exhaustion.
Background polling runs every 120s.
UI remains stable without flicker.
Safe behavior during tab transitions/unmounts