fix: dialer leaking resources after stopping #947
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
achingbrain
requested changes
May 28, 2021
|
|
||
| await libp2p.stop() | ||
| await expect(dialPromise) | ||
| .to.eventually.be.rejected() |
There was a problem hiding this comment.
This assertion should be be expanded to ensure the right type of error is being thrown.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the potential leaking of resources in the dialer on stop.
During the
transport.dialflow, if libp2p is stopped the on going dials were being aborted. However, situations like libp2p/js-libp2p-tcp#142 were possible when a given resolvable multiaddr (dnsaddr) is being resolved before getting into the transport level. This would result in new dial attempts after stop and established connections that prevented the process from properly stop.Unfortunately, node's dns record resolution does not allow the lookup to be abortable. As a consequence, this PR adds a competing Cancellable promise, which will be rejected in case of
libp2p.stop()=>dialer.destroy(). With this, the promise that would resolve thedialTargetwill be rejected and the current on going dial all together.Moreover, as described in #779 the latency monitor was not being properly closed. So, I also added
startandstopfunctions to it (instead of the really odd pattern of starting it in the constructor).Closes #779