-
Notifications
You must be signed in to change notification settings - Fork 10
fix: Drop duplicated received filter update #248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughRemoved the per-height received-filter tracking block from the message handler; the handler still updates overall filter statistics and last-filter-received timestamp but no longer inserts block heights into the shared received-filter-heights set. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
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 |
This fixes an issue introduced in #211 where the `receiver_filter_heights` lock isn't released after inserting the received height, and then the same task tries to acquire the lock again just a bit below in `mark_filter_received` -> deadlock. So, #211 should have not introduced the filter height updates here since they already exist in `mark_filter_received`. Yet the stats updates introduced in the same place are legit.
9521500 to
ccccc6b
Compare
This fixes an issue introduced in #211 where the `receiver_filter_heights` lock isn't released after inserting the received height, and then the same task tries to acquire the lock again just a bit below in `mark_filter_received` -> deadlock. So, #211 should have not introduced the filter height updates here since they already exist in `mark_filter_received`. Yet the stats updates introduced in the same place are legit.
This fixes an issue introduced in #211 where the `receiver_filter_heights` lock isn't released after inserting the received height, and then the same task tries to acquire the lock again just a bit below in `mark_filter_received` -> deadlock. So, #211 should have not introduced the filter height updates here since they already exist in `mark_filter_received`. Yet the stats updates introduced in the same place are legit.
This fixes an issue introduced in #211 where the
receiver_filter_heightslock isn't released after inserting the received height, and then the same task tries to acquire the lock again just a bit below inmark_filter_received-> deadlock.So, #211 should have not introduced the filter height updates here since they already exist in
mark_filter_received. Yet the stats updates introduced in the same place are legit.Summary by CodeRabbit
Bug Fixes
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.