fix(cache): release RBCache mutex lock before sending notifications#828
fix(cache): release RBCache mutex lock before sending notifications#828matthyx wants to merge 1 commit into
Conversation
|
Warning Review limit reached
More reviews will be available in 43 minutes and 25 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 (2)
📝 WalkthroughWalkthroughRBCache refactors notification delivery from synchronous sends (blocking handler execution) to asynchronous queuing. Handlers now snapshot notifiers and enqueue notifications non-blockingly; a background goroutine processes the queue and dispatches events. NewCache and NewCacheMock both initialize the queue and start the processor. ChangesAsynchronous notification queue architecture
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
db32b73 to
b2d10c7
Compare
Performance Benchmark ResultsNode-Agent Resource Usage
Dedup EffectivenessNo data available. |
b2d10c7 to
7ab1afb
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@pkg/rulebindingmanager/cache/cache.go`:
- Around line 74-82: The processNotifications loop in RBCache (function
processNotifications reading from notificationQueue and iterating
pn.notifiers/pn.events) uses a blocking send (*n <- event) which can stall the
whole goroutine if any notifier channel is full or slow; change the send to a
non-blocking pattern (use a select with the channel send case and a default case
to drop-and-log, or use a select with a time.After timeout to drop+log after a
short wait) so a single bad notifier cannot block processing of
notificationQueue and other notifiers; ensure you log dropped events with
context (which notifier and event) for observability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: dacc15b2-3805-4898-a6e8-3219af2c0903
📒 Files selected for processing (2)
pkg/rulebindingmanager/cache/cache.gopkg/rulebindingmanager/cache/mock.go
Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
7ab1afb to
308553b
Compare
Performance Benchmark ResultsNode-Agent Resource Usage
Dedup EffectivenessNo data available. |
Performance Benchmark ResultsNode-Agent Resource Usage
Dedup EffectivenessNo data available. |
Releases the RBCache mutex lock before sending rule-binding/pod notifications to channels in AddHandler, ModifyHandler, and DeleteHandler. This resolves the RBCache deadlock which blocks all event processing workers and results in unbounded memory growth (OOM).
Summary by CodeRabbit