Go-ipfs: IPNS: context deadline exceeded

[ligi]

I was excited to read that 0.5 speeds up IPNS. So I wanted to give it a spin. Unfortunately I get an error now:

ligi@komputing:~$ ipfs add -Q -r /opt/source-verify/production/source-verify/repository/
QmfXZmzSaEZvEWrJtTjJkmXDV5Dpoxz2diHFPHvnsrexa3
ligi@komputing:~$ ipfs name publish QmfXZmzSaEZvEWrJtTjJkmXDV5Dpoxz2diHFPHvnsrexa3
Error: context deadline exceeded

running this version:

go-ipfs version: 0.5.0
Repo version: 9
System version: amd64/linux
Golang version: go1.13.10

[aschmahmann]

@ligi there are a number of IPNS related improvements in the 0.5 release. However, IPNS Publishing (like IPFS Providing) on the DHT will still not be as fast as indicated by testing until more of the network upgrades (for posterity this issue was filed on day one of the release).

Even on day one of the release publishing IPNS records should still be faster than in 0.4.23 and earlier though.

[ligi]

@aschmahmann thanks for the info - advocating the migration to 0.5.0 even more then ;-)
btw.: can I increase the context deadline somehow?

[aschmahmann]

@ligi at first glance it doesn't look like there is, but that seems like something you should be able to do. Thanks for the bug report 😄.

[ligi]

My pleasure - thanks for your work!

[santhoshtr]

Upgraded to 0.5.0 and facing the same issue when running publish using http api

TimeoutError: context deadline exceeded
    at Object.errorHandler [as handleError] (/home/santhosh/work/exp/ipfs/node_modules/ipfs-http-client/src/lib/core.js:71:13)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Client.fetch (/home/santhosh/work/exp/ipfs/node_modules/ipfs-utils/src/http.js:145:9)
    at async Object.publish (/home/santhosh/work/exp/ipfs/node_modules/ipfs-http-client/src/name/publish.js:9:17)

[xmaysonnave]

Dear Friends,

I'm facing the same issue than @santhoshtr
However from my understanding I noticed the following behaviour.
Even this exception is raised the update is successfully published on my local IPFS server.
I understand that this issue is related to the fact that my local dev server is behind a NAT/Firewall.
I also understand that remote peers will no get the update at this point.

However I'm wondering if at some point the server will try again by itself to publish the IPNS update. Let's say that this local server at some point is exposed to its peers through a public IP address. What happened then ???

The ultimate concern is the way I need to handle this issue in my DApp. Warning or errors as the update is available locally. Currently as the update is available locally I consider it as warning (bit will it be published to remote peers later ??)

Hope its clear.

Thanks

[vrde]

[crossposting from twitter]
I tried to publish the cid @ligi posted and I got the same error on v0.5.0:

➜  ~ ipfs name publish QmfXZmzSaEZvEWrJtTjJkmXDV5Dpoxz2diHFPHvnsrexa3
Error: context deadline exceeded

[sinkuu]

When I encounter this problem, the daemon logs a "error when determining the last published IPNS record" (using ipfs log level namesys debug). It would be nice if CLI client shows that message in addition to the obscure "context deadline exceeded".

Apr 29 20:11:19 localhost ipfs[342]: 2020-04-29T20:11:19.383+0900        DEBUG        namesys        namesys/publisher.go:126        error when determining the last published IPNS record for Qmak3N3ey6AAGndq5zwZD3N2oP5gJkS4A8QGEqVUR7J7gT: context deadline exceeded
Apr 29 20:11:19 localhost ipfs[342]: [153B blob data]
Apr 29 20:11:19 localhost ipfs[342]: [159B blob data]

[aschmahmann]

@sinkuu the error returned isn't actually from error when determining the last published IPNS record since if you look at that line in publisher.go it returns no error, just a debug log.

What is happening instead is that the Publish part has been hard coded to have a 1 minute timeout https://github.com/ipfs/go-ipfs/blob/36789eaa88a7277c06a22b7955f128409c705746/namesys/publisher.go#L277-L278 and that seems unfortunate since the user should be able to let the query go longer than that if they want.

[achingbrain]

It would be really helpful if that timeout was configurable, either globally or as a command option - we'd be able to shave a few minutes off an interop test run as they spend a long time doing nothing while they wait for the timeouts to expire.

[Stebalien]

Let's remove that timeout for now.

[xmaysonnave]

https://github.com/ipfs/go-ipfs/pull/7256#issuecomment-623869140

[aschmahmann]

For anyone coming to this issue in between v0.5.0 and v0.5.1 here's the summary:

Sometime IPNS publishing takes over a minute and times out giving you the error "context deadline exceeded", this one minute timeout has been removed and will be part of the next patch release.

Note: As of today (about a week after the release) IPNS publishes normally finish in less than a minute (I get about 30 seconds). However, there are DHT lookups that take longer than a minute. Trying again frequently works. As more of the network adopts v0.5.0 the network will improve and lookup times for IPNS should improve.

[RubenKelevra]

It would be really helpful if that timeout was configurable, either globally or as a command option - we'd be able to shave a few minutes off an interop test run as they spend a long time doing nothing while they wait for the timeouts to expire.

The timeout is configurable:

[ruben@i3 ~]$ time ipfs --api="/ip6/::1/tcp/5001" name publish --timeout=1s --key="test" bafybeihtwu6nkwgidugswmwwvsqqukl7cmhf6ne5f3cqi2ocedsbjmmvfe
Error: context deadline exceeded

real    0m1,044s
user    0m0,031s
sys     0m0,030s
[ruben@i3 ~]$ time ipfs --api="/ip6/::1/tcp/5001" name publish --timeout=5s --key="test" bafybeihtwu6nkwgidugswmwwvsqqukl7cmhf6ne5f3cqi2ocedsbjmmvfe
Error: context deadline exceeded

real    0m5,044s
user    0m0,028s
sys     0m0,033s

[achingbrain]

The --timeout option is a global cli option that makes the operation return a non-zero exit code after the specified timeout.

This is not the timeout I'm referring to, I'm talking about the one Adin mentions:

What is happening instead is that the Publish part has been hard coded to have a 1 minute timeout

Sorry if that's wasn't clear.

[Stebalien]

This timeout has been removed in 0.5.1.