sharness suite: ipfs name publish: “Error: failed to find any peer in table”

[ion1]

ipfs name publish fails with “Error: failed to find any peer in table” in the sharness suite when the daemon is running.

(There are no peers intentionally, ipfs bootstrap rm --all is executed in test/sharness/lib/test-lib.sh.)

[rht]

@ion1 this is covered in the test: test_resolve_fail, test_resolve_cmd_fail in https://github.com/ipfs/go-ipfs/blob/master/test/sharness/t0160-resolve.sh.

I think this is caused by 7ad8dd8, which is intentional?

[ion1]

The comment for test_resolve_fail is:

#todo remove this once the online resolve is fixed

[rht]

Yes it is meant to be removed.

Maybe there should be ipfs name commit?

[ion1]

I think ipfs name publish should work while the daemon is running without peers just like it does when the daemon is not running. The existing tests (which use test_expect_failure due to this issue) seem to expect that behavior, too.

[rht]

Either that, or use ipfs name commit for 'daemon off' and 'daemon on but no peer' case (and reserve ipfs name publish when it is possible to publish to peers).
It would be confusing to publish while offline, when there is no pending action/promise to execute when the daemon is on.

[rht]

related #1593

[whyrusleeping]

should probably have a --local flag on this one too.

[jbenet]

What do we want the UX to be? I can see cases for:

• ipfs name publish fails when disconnected. use --local to allow adding a local name, and then propagate it when connected.
• ipfs name publish works even if disconnected. propagate later. maybe warn user that it's offline, so they get the needed feedback (tricky programmatically). maybe add a --online flag to ensure it's online and fail otherwise.

[whyrusleeping]

I don't like the UX of a --online option, I think having the --local option, or just having it work when offline

[ion1]

An “is daemon online” test in the beginning has a race condition. Perhaps the network connection disappears immediately after it.

Perhaps it would be better to make an asynchronous/synchronous distinction.

Default: asynchronous – succeed immediately, best effort to publish the name whenever the daemon is running and online.

Optional: synchronous – fail if the daemon is not running; wait until the record has been added to DHT otherwise.

[whyrusleeping]

These issues should be mitigated by using iptb for tests. You should be able to spin up an iptb cluster (as in t0130-multinode.sh) and do ipns publishes just fine

[ToxicFrog]

FYI, this is still an issue in 0.4.13 and 0.4.14. In particular, it means if you're running a private swarm with a single node or with intermittent connectivity, ipfs name publish effectively can't be used at all.

[jukbot]

I'm getting an error ERROR ipns-repub: Republisher failed to republish: failed to find any peer in table core.go:518

current IPFS version of 0.4.14 any solution for working around?

[ToxicFrog]

@vyzo on IRC suggested trying --enable-namesys-pubsub, but no dice:

$ pgrep -laf ipfs
29526 /nix/store/9v5yn8v1sq41753aib3kfqpb6b95v05z-ipfs-0.4.14-bin/bin/ipfs \
          daemon --enable-gc --enable-namesys-pubsub

$ ipfs key list -l | grep testkey
QmavpF6QAS7C6TSHvrGASJVw1hXLD7qphTZ7kR5WjzjAjM testkey

$ ipfs name publish --key=testkey /ipfs/QmTVKRqMywTwwngjTQB8CKycaFQwQHPbd9jdzQv8L9cuqK
Error: failed to find any peer in table

$ ipfs name resolve /ipns/QmavpF6QAS7C6TSHvrGASJVw1hXLD7qphTZ7kR5WjzjAjM
Error: Could not resolve name.

[vyzo]

You need to resolve once in the peer first, so that it is subscribed to the topic before the publisher publishes.

[ToxicFrog]

There is only one peer involved; it's a single-node swarm. Running ipfs name resolve before ipfs name publish as well as after does not change the behaviour.

[vyzo]

I think the issue here is that the rendezvous for ipns pubsub happens through DHT provider records.
If the DHT can't bootstrap because there are no peers to start the DHT, then it will neuter the functionality.

Btw, you need your two peers connected before you publish. If they are not, then the rendezvous for pubsub will fail, and the peer will fail to see the published record.

[vyzo]

Per discussion on irc:

It seems that this intentionally a single peer, not connected to anything; so it's a BUG.

[origama]

So guys, I just want to bump this issue since I am facing it in this moment.
I am trying to setup a private network, I have a single node publishing content to a specific key. When this happens the node could be alone, after this a certain number of peers will start, connect to the peer and eventually try resolving that ipns name.
Everytime the first node tries to publish when is not connected it fails with Error: failed to find any peer in table

I even tried to use the --local option (undocumented in the command help) but it is not helping.

EDIT: I forgot to mention that I am on

# ipfs version
ipfs version 0.4.17

[ToxicFrog]

For the record, this is still broken in 0.4.18:

$ ipfs key list -l                                                                                                                                          
QmavpF6QAS7C6TSHvrGASJVw1hXLD7qphTZ7kR5WjzjAjM testkey

$ ipfs name publish --key=testkey QmQn5kVnA9bd2msDdGrxB47yfbxku3hkUoGudu5z6JDpCk                                                            
Error: failed to find any peer in table

$ ipfs name publish --key=testkey --local QmQn5kVnA9bd2msDdGrxB47yfbxku3hkUoGudu5z6JDpCk                                                            
Error: failed to find any peer in table

$ ipfs name publish --key=testkey --allow-offline QmQn5kVnA9bd2msDdGrxB47yfbxku3hkUoGudu5z6JDpCk                                                            
Error: failed to find any peer in table

$ ipfs name resolve /ipns/QmavpF6QAS7C6TSHvrGASJVw1hXLD7qphTZ7kR5WjzjAjM
[hangs for a really long time, then]
Error: could not resolve name

[ToxicFrog]

The documentation for --allow-offline implies it should do exactly what I want:

  --allow-offline           bool   - When offline, save the IPNS record to the the local datastore without
                                     broadcasting to the network instead of simply failing.                                                                                                                                                        

I'm not sure if this is a matter of me not understanding the documentation, the documentation being wrong, or a bug preventing --allow-offline from actually working. Perhaps it only applies if node was started with --offline, and not if the node is in "online mode" but not actually connected to anything?

[Stebalien]

For the record, this is still broken in 0.4.18:

--allow-offline was added to allow publishing while running in offline mode (or in combination with the new --offline flag. However, it should probably work in this case as well. That is, it should allow publishing to succeed even if the actual publish step fails.

[ToxicFrog]

After some testing, it does in fact work in --offline mode (which I previously wasn't using because of #4389 but now have a workaround for). So that's good enough for my purposes. I agree that it should work in "online but not actually connected to anything" mode, though -- even if it can't broadcast the new IPNS entry you should still be able to look it up locally.