-
Notifications
You must be signed in to change notification settings - Fork 94
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
fix(bitswap/client/msgq): prevent duplicate requests #691
base: main
Are you sure you want to change the base?
Conversation
if mq.bcstWants.sent.Len() == 0 && mq.peerWants.sent.Len() == 0 { | ||
return false | ||
mq.rebroadcastIntervalLk.RLock() | ||
rebroadcastInterval := mq.rebroadcastInterval |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, this could be a different new parameter/constant
I tested this on a k8s cluster and with a local node connected to it. It works as expected, but I believe this would benefit a lot from a proper test. Unfortunately, I can't allocate time to writing one. It's not that straightforward. |
For context, I detect duplicates with a custom multihash that logs out when the same data is hashed again. This essentially uncovered #690, and this issue |
070d0e4
to
d193c2f
Compare
Previously, in-progress requests could be re-requested again during periodic rebroadcast. The queue requests, and while awaiting response, the rebroadcast event happens. Rebroadcast event changes previosly sent WANTs to pending and sends them again in a new message. The solution here is to ensure WANT was in sent status for long enough, before bringing it back to pending. This utilizes existing `sendAt` map which tracks when every CID was sent.
d193c2f
to
9020b71
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
@@ Coverage Diff @@
## main #691 +/- ##
==========================================
+ Coverage 60.36% 60.39% +0.03%
==========================================
Files 243 243
Lines 31034 31048 +14
==========================================
+ Hits 18734 18752 +18
+ Misses 10634 10633 -1
+ Partials 1666 1663 -3
|
Previously, in-progress requests could be re-requested again during periodic rebroadcast. The queue requests, and while awaiting a response, the rebroadcast event happens. Rebroadcast event changes previously sent WANTs to pending and sends them again in a new message, duplicating some WANT requests.
The solution here is to ensure WANT was in sent status for long enough before bringing it back to pending. This utilizes the existing
sendAt
map, which tracks when every CID was sent. Then, on every event, it compares if the message was around longer thanrebroadcastInterval