Using signaling node. Error: there is already a transport with this key

[vongohren]

• Version:
  0.32.3 - IPFS.js
• Platform:
  macOS
• Subsystem:

Type:

Bug & Question

Severity:

High

Description:

Im running a monorepo with a node server and a static frontend.
The static frontend initializes a ipfs with

const ipfsOptions = {
  EXPERIMENTAL: {
    pubsub: true
  },
  config: {
    Addresses: {
      Swarm: [
        // Use IPFS dev signal server
        // '/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star',
        '/dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star',
        // Use local signal server
        // '/ip4/0.0.0.0/tcp/9090/wss/p2p-webrtc-star',
      ]
    },
  },
}

The backend does the same.
The backend responds with
Swarm listening on /dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star/ipfs/QmdrQugzDcTXm5TFR6VwHdHmTziVFfsqJLeqs3wVtCsUcL

The frontend tries to connect, but IPFS never gets the event ready, but responds with the error

transport.js:51 Uncaught Error: There is already a transport with this key
    at TransportManager.add (transport.js:51)
    at index.js:197
    at parallel.js:34
    at replenish (eachOfLimit.js:78)
    at iterateeCallback (eachOfLimit.js:57)
    at onlyOnce.js:13
    at parallel.js:40
    at once.js:13
    at iteratorCallback (eachOf.js:65)
    at onlyOnce.js:13
    at transport.js:172
    at parallel.js:43
    at once.js:13
    at iteratorCallback (eachOf.js:65)
    at onlyOnce.js:13
    at parallel.js:40
    at f (once.js:24)
    at transport.js:159
    at listener.js:327
    at setImmediate.js:33
    at run (setImmediate.js:48)
    at runIfPresent (setImmediate.js:83)
    at onGlobalMessage (setImmediate.js:125)

I cannot seem to initialize the frontend with the same signaling node as the backend.

Is this because im in a monorepo?
Meaning that there is a hoisting of ifps-js, meaning that they share the keys? I thought that the web client ran everything in the browser, independent of the filesystem.

Is this because im not defining repo in the config?
If so, I have tried defining different paths for the repo in the config, but there is no difference.

Steps to reproduce the error:

Have a lerna monorepo with a client and a backend.
Use the config descripted above.
Initialize the ipfs for both backend and frontend.
Backend is quicker so that gets the signaling node in the swarm listening.
Fails when frontend tries to open ipfs for some reason, hopefully with the error descripted.

[alanshaw]

Thanks for reporting @vongohren - would you be able to retry with 0.33.1? There were significant libp2p improvements that might have already fixed this.

[vongohren]

Not a whole lot of changes to this error with 0.33.1 unfortunately. @alanshaw

After removing that configuration, i still keep getting the problem, which forces me to clear the indexed DB to be able to not getting the error, because of that first initialization with that conifg.

I can either remove it, or add a repo config forcing a new storage path

[mauriciomelo]

I can confirm the same issue here, with ipfs 0.33.1 and node 11.x and 8.x

[alanshaw]

@jacobheun / @vasco-santos any idea what's going on here?

[jacobheun]

@alanshaw yes, an issue was opened in libp2p libp2p/js-libp2p#291.

That has been fixed and released in libp2p@0.24.2, but will require a js-ipfs release to rollout to users with the update to libp2p 0.24.x

[alanshaw]

@vongohren @mauriciomelo I'm going to close this issue as it should now be fixed. 0.34 will be released soon (track it here #1721) and a RC even sooner. Until then you have the slightly more risky option of depending on master. If you have a moment to test it out and report back that would be amazing. Good luck!