-
Notifications
You must be signed in to change notification settings - Fork 918
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(discovery): findCtx is canceled too early by defer #2180
fix(discovery): findCtx is canceled too early by defer #2180
Conversation
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.
Let's comment that the order matters.
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.
I would just group the defer statements into a
defer func() {
wg.Wait()
findCancel()
}()
so the ordering of exec is explicitly clear.
alternatively make comment but i think if the ordering matters that much, it's better to make explicitly obvious
Codecov Report
@@ Coverage Diff @@
## main #2180 +/- ##
==========================================
- Coverage 56.04% 55.83% -0.22%
==========================================
Files 215 215
Lines 13918 13922 +4
==========================================
- Hits 7800 7773 -27
- Misses 5340 5367 +27
- Partials 778 782 +4
|
The order of exec is clear and deterministic with defer as well, but I don't mind grouping them in one defer |
Overview
If underlying discovery.FindPeers closes the channel,
discover
call would return calling the defer stack and cancelingfincCtx
too early. This would result in all routines trying to establish connection being canceled before having time to succeed. Fixed by changing defer stack order ofwg.Wait
andcontext.Cancel
calls.The change also fixes flaky
get_peer_from_discovery
test, since flakiness was actually a bug.