Skip to content

fix: do not use hard coded IPNS Publish maximum timeout duration#7256

Merged
Stebalien merged 1 commit intomasterfrom
fix/7244
Apr 29, 2020
Merged

fix: do not use hard coded IPNS Publish maximum timeout duration#7256
Stebalien merged 1 commit intomasterfrom
fix/7244

Conversation

@aschmahmann
Copy link
Contributor

fixes #7244

Sometimes IPNS publishes can take longer than a minute. Since DHT lookups now terminate without needing to query a huge portion of the network (even if the lookups take a while until more of the network upgrades to v0.5.0+), we should allow the user's IPNS queries to go on until they're ready to cancel them.

Note: There's still a 30 second timeout on doing a record Get before Publishing, however this doesn't bother me too much since it both doesn't cause an error to be returned and the whole code path is a bit strange in general since it seems to only get called if either:

  1. The IPNS key is first being used (in which case we expect the Get to return no info, so we might as well have a timeout)
  2. The datastore (not the blocks section, but the rest of the datastore) has been cleaned out/restored from a backup (not really supported)
  3. The IPNS key is being added to a new machine (also not supported)

@aschmahmann aschmahmann self-assigned this Apr 29, 2020
@xmaysonnave
Copy link

Today while working on HTTPError and TimeoutError while publishing and IPNS name I realized that even I'm behind a nat/firewall the errors vanished when I deactivated my DNSCrypt (Debian Buster).

@Stebalien Stebalien mentioned this pull request May 26, 2020
77 tasks
@hacdias hacdias deleted the fix/7244 branch May 9, 2023 10:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IPNS: context deadline exceeded

3 participants