ipfs.stop(cb) not calling cb, looks like in libp2p.stop in [discovery].map.stop

[mitra42]

• Version: "0.31.7"
• Platform: Mac OSX running node.
• Subsystem: libp2p.stop I believe

Type: Bug

Severity: High ? The API is not working as described, (no significant impact on me)

Description:

I recently added node.stop((err, res) => debug("IPFS ended")) to my system because I was seeing that my crawl script (for archive.org) was not exiting correctly if IPFS was connected.

While this appeared to stop IPFS (the script now exits), the debug line is never called.

Using breakpoints in the IDE the problem appears to be in

• ipfs/source/core/components/stop.js which gets the callback from self._mfsPreload.stop but not from self.libp2p.stop(cb). Digging deeper, in
• /Users/mitra/git/dweb-mirror/node_modules/libp2p/src/index.js in stop()
  which never completes the first step in the series, i.e. the if (this._floodSub) is never called. I don't know libp2p well enough to dig deeper into the parallel code at

return parallel(
            this._discovery.map((d) => {
              return (_cb) => d.stop(() => { _cb() })
            }),
            cb
          )

To see why the cb is not called back

I suspect, from the history of similar issues in #1168 that its config dependent, Note my config includes wss and is:

{
  "repo": "/tmp/dweb_ipfsv3107",
  "config": { "Bootstrap": [ "/dns4/dweb.me/tcp/4245/wss/ipfs/QmQ921MRjsbP12fHSEDcdFeuHFg6qKDFurm2rXgA5K3RQD" ] },
  "EXPERIMENTAL": { "pubsub": true },
  "preload": {    "enabled": false  }
}

Steps to reproduce the error:

I am seeing this in a fairly complex piece of code, which I will try and strip down to its basics but to repeat it ...

git clone https://github.com/internetarchive/dweb-mirror#jsipfsissue1806
cd dweb-mirror
npm install
mkdir ~/temp/mirrored
./crawl.js 

At the end it outputs HTTP is stopped and should, but doesnt output IPFS is stopped.

I will attempt to reduce to something simpler, but I suspect that whatever causes IPFS not to exit correctly is may mean that once it is reduced that the problem goes away.

[alanshaw]

@jacobheun I think the state machine change in libp2p has left it unable to pass an error to the callback provided to start or stop and instead emits an error event that is not being listened for and the callback is never called.

I think this is the same issue as libp2p/js-libp2p#311

[jacobheun]

I think the state machine change in libp2p has left it unable to pass an error to the callback provided to start or stop and instead emits an error event that is not being listened for and the callback is never called.

Confirmed, looking into it.

I think this is the same issue as libp2p/js-libp2p#311

This would contribute, but I don't think it's the only issue. I will fix the libp2p issue and will check if there is something else causing problems.

[alanshaw]

Should now be fixed by combination of libp2p/js-libp2p#316 and #1860 and will be released in 0.35.