fix: remove timeout on default DHT operations #9783
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
This removes the timeout by default for DHT operations. In particular this causes issues with ProvideMany requests which can take an indeterminate amount of time, but really these should just respect context timeouts by default. Users can still specify timeouts here if they want, but by default they will be set to "0" which means "no timeout". This is unlikely to break existing users of custom routing, because there was previously no utility in configuring a router with timeout=0 because that would cause the router to immediately fail, so it is unlikely (and incorrect) if anybody was using timeout=0.
guseggert
force-pushed
the
feat/composed-router-timeout
branch
from
a508ead
to
5fda291
Compare
For context see 5fda291
lidel
approved these changes
Mar 30, 2023
There was a problem hiding this comment.
we had another 5m timeout in func Routing(in p2pOnlineRoutingIn) irouting.ProvideManyRouter, pushed a fix too.
Tests in go-libp2p-routing-helpers should be good enough.
Let's merge it and ask someone with big repo and announce problem (#9722) to test 0.20-rc1 when it's out (or to build from master)
|
@guseggert : I think this needs a changelog entry (or is that happening elsewhere)? |
|
Closed
galargh
pushed a commit
that referenced
this pull request
Apr 4, 2023
* fix: remove timeout on default DHT operations This removes the timeout by default for DHT operations. In particular this causes issues with ProvideMany requests which can take an indeterminate amount of time, but really these should just respect context timeouts by default. Users can still specify timeouts here if they want, but by default they will be set to "0" which means "no timeout". This is unlikely to break existing users of custom routing, because there was previously no utility in configuring a router with timeout=0 because that would cause the router to immediately fail, so it is unlikely (and incorrect) if anybody was using timeout=0. * fix: remove 5m timeout on ProvideManyRouter For context see 5fda291 --------- Co-authored-by: Marcin Rataj <lidel@lidel.org>
galargh
added a commit
that referenced
this pull request
Apr 5, 2023
* chore: update version * chore: update go-libp2p to v0.26.4 * fix: remove timeout on default DHT operations (#9783) * fix: remove timeout on default DHT operations This removes the timeout by default for DHT operations. In particular this causes issues with ProvideMany requests which can take an indeterminate amount of time, but really these should just respect context timeouts by default. Users can still specify timeouts here if they want, but by default they will be set to "0" which means "no timeout". This is unlikely to break existing users of custom routing, because there was previously no utility in configuring a router with timeout=0 because that would cause the router to immediately fail, so it is unlikely (and incorrect) if anybody was using timeout=0. * fix: remove 5m timeout on ProvideManyRouter For context see 5fda291 --------- Co-authored-by: Marcin Rataj <lidel@lidel.org> * chore: bump go-blockservice to v0.5.1 * chore: update version * chore: update changelog for v0.19 --------- Co-authored-by: Jorropo <jorropo.pgm@gmail.com> Co-authored-by: Gus Eggert <gus@gus.dev> Co-authored-by: Marcin Rataj <lidel@lidel.org>
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 removes the timeout by default for DHT operations. In particular this causes issues with ProvideMany requests which can take an indeterminate amount of time, but really these should just respect context timeouts by default. Users can still specify timeouts here if they want, but by default they will be set to "0" which means "no timeout".
This is unlikely to break existing users of custom routing, because there was previously no utility in configuring a router with timeout=0 because that would cause the router to immediately fail, so it is unlikely (and incorrect) if anybody was using timeout=0.