-
Notifications
You must be signed in to change notification settings - Fork 16
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
Exchange Head single-flight protection #229
base: main
Are you sure you want to change the base?
Exchange Head single-flight protection #229
Conversation
Hey @IliaBulavintsev, thanks for the contribution. Note that the issue this PR targets is meant to cover all the methods and not only |
Hey @Wondertan ! Thank you for your review. The implementation was meant to only cover |
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.
This is a great start :) just a few things
- can you please remove the
sync_getter
from the syncer component as now the single flight protection has moved to the exchange instead? - re tests: they are comprehensive and have good coverage, but I think they may be a bit overkill. Testing 2 to max 3 simultaneous requests would be sufficient. Also the
requestFromTrusted
param in the tests would be more useful in terms of coverage if it was false for some cases. - nit: the tests could benefit from a bit of spacing between statements for readability :)
- test case with untrusted peer
Hey @renaynay!
Lmk if you have other feedback |
p2p/exchange_test.go
Outdated
{ | ||
requestFromTrusted: true, | ||
lastHeader: trustedStore.Headers[trustedStore.HeadHeight-1], | ||
expectedHeight: trustedStore.HeadHeight, | ||
expectedHash: trustedStore.Headers[trustedStore.HeadHeight].Hash(), | ||
}, | ||
{ | ||
requestFromTrusted: true, | ||
lastHeader: trustedStore.Headers[trustedStore.HeadHeight-1], | ||
expectedHeight: trustedStore.HeadHeight, | ||
expectedHash: trustedStore.Headers[trustedStore.HeadHeight].Hash(), | ||
}, |
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.
what's the difference between these two test cases?
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.
The duplicate cases serve to double-check that singleflight
consistently returns the same response for identical requests from a trusted
source. However, if you think a single case is sufficient for validation, we can remove the duplicates to streamline the test
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.
That seems like a good test generally-speaking but I don't think it is relevant to the single-flight protection feature and should rather be implemented in a different way. I appreciate the thought here, however.
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.
Got it, I’ll remove the test as it’s not directly relevant to single-flight. Thanks for the feedback!
#154
Overview
This PR adds singleflight protection to prevent duplicate header requests in the Exchange component. The focus is on minimizing redundant requests, especially around the Head method, which is most likely to experience simultaneous calls.