Conversation
notificationsMutationSuccessCallback was calling invalidateQueries without refetchType, causing an immediate GET /user_notifications?limit=500 every time a notification was marked as read (e.g. opening a channel from the sidebar). The optimistic update in onMutate already applies the correct cache state, so the refetch is unnecessary. Adding refetchType: 'none' marks the data as stale without triggering a network request.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 20 minutes and 33 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
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 |
Summary
notificationsMutationSuccessCallbackwas callinginvalidateQuerieswithoutrefetchType, which defaults to'active'— triggering an immediateGET /user_notifications?limit=500every time a notification mutation succeedsMarkMessageNotifications, which callsmarkAsRead→ triggers the seen mutation → success callback refetches all 500 notificationsrefetchType: 'none'so the invalidation marks cached data as stale without an immediate refetch — the optimistic update inonMutatealready applies the correct cache state🤖 Generated with Claude Code