Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circuit Relay test is failing. #198

Closed
daviddias opened this issue May 28, 2018 · 8 comments
Closed

Circuit Relay test is failing. #198

daviddias opened this issue May 28, 2018 · 8 comments
Assignees
Labels
exp/expert Having worked on the specific codebase is important kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up

Comments

@daviddias
Copy link
Member

daviddias commented May 28, 2018

@jacobheun could this have been introduced with the refactor? It seems that the muxer on the connection is not being correctly set up when a Relay connection happens.

  1) circuit relay
       "after all" hook:
     Uncaught TypeError: Cannot read property 'muxer' of undefined
      at each (node_modules/libp2p-switch/src/index.js:113:14)

//cc @dryajov

@daviddias daviddias added kind/bug A bug in existing code (including security flaws) exp/expert Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up labels May 28, 2018
@jacobheun
Copy link
Contributor

@diasdavid I'll take a look at this, I think it's just an issue with resiliency when a peer hangs up while we're also shutting down. If a peer hangs up at the same time we're shutting down (such as with test cases), it's possible we could remove the muxed connection on the hang up, as we're iterating on them to shut each of them down, making the connection undefined. I'll make sure this is the case and improve the resiliency to prevent this error.

@daviddias daviddias added the status/ready Ready to be worked label May 29, 2018
@ghost ghost assigned jacobheun May 29, 2018
@ghost ghost added status/in-progress In progress and removed status/ready Ready to be worked labels May 29, 2018
@jacobheun
Copy link
Contributor

My assumption was correct, I have the update ready here libp2p/js-libp2p-switch#260. The PR also links to the passing CI tests for libp2p via the chore/update-switch branch.

@jacobheun
Copy link
Contributor

@diasdavid this is fixed in the latest release of switch, 0.40.3. There's another issue with the tests failing. I'll see if I can figure out what's going on there.

  1) transports TCP + WebSockets + WebRTCStar nodeAll.dial nodeWStar using PeerInfo:
     Error: Timeout of 40000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
  2) transports TCP + WebSockets + WebRTCStar nodeAll.hangUp nodeWStar using PeerInfo:
      Uncaught AssertionError: expected [] to have a length of 1 but got 0
      + expected - actual
      -0
      +1
  
      at forEach (test/transports.node.js:455:61)
      at Array.forEach (<anonymous>)
      at check (test/transports.node.js:454:28)
      at Timeout.setTimeout [as _onTimeout] (test/transports.node.js:506:26)

https://ci.ipfs.team/blue/organizations/jenkins/libp2p%2Fjs-libp2p/detail/chore%2Fupdate-switch/5/pipeline

@jacobheun
Copy link
Contributor

js-libp2p-webrtc-star v0.15.2 is breaking the tests, looking into it.

@daviddias
Copy link
Member Author

Thank you @jacobheun :)

@jacobheun
Copy link
Contributor

The underlying issue appears to be with multistream-select and block-streams, which were added via libp2p/js-libp2p-webrtc-star#145, they are not playing well together.

I am looking into why that's the case. I have tested this against pull-block and block-streams and both consistently hang, which explains the hang in the tests we are seeing in libp2p.

@diasdavid I think we might want to rollback the update to libp2p-webrtc-star until this is resolved as the multistream connections won't work. I know @ya7ya is also looking into updates for block streams to fix ipfs/js-ipfs#1379, so it might be good to roll those together. If I can get the multistream-select/block-stream fix done, it should make it so we can use pull-block (I am adding tests to multistream-select using pull-block).

additional info

I am seeing a clear, consistent, order of operations difference in the calls between block and non block usage.

without block streams (working)

  mss:dialer     (1plvt5) dialer handle conn +0ms
  mss:dialer     (1plvt5) writing multicodec: /multistream/1.0.0 +1ms
  mss:listener   (dwutnx) listener handle conn +0ms
  mss:listener   (dwutnx) writing multicodec: /multistream/1.0.0 +0ms
  mss:listener   (dwutnx) received ack: /multistream/1.0.0 +3ms
  mss:listener   (dwutnx) adding handler: /monkey/1.0.0 +2ms
  mss:dialer     (1plvt5) received ack: /multistream/1.0.0 +209ms
  mss:dialer     (1plvt5) handshake success +1ms
  mss:dialer     (1plvt5) dialer select /monkey/1.0.0 +0ms
  mss:dialer     (1plvt5) writing multicodec: /monkey/1.0.0 +0ms
# truncated here, but the logs continue

with block streams (hanging)

  mss:dialer     (1sx1xq) dialer handle conn +0ms
  mss:dialer     (1sx1xq) writing multicodec: /multistream/1.0.0 +0ms
  mss:listener   (1xawf5) listener handle conn +0ms
  mss:listener   (1xawf5) writing multicodec: /multistream/1.0.0 +0ms
  mss:dialer     (1sx1xq) received ack: /multistream/1.0.0 +202ms
  mss:dialer     (1sx1xq) handshake success +0ms
  mss:dialer     (1sx1xq) dialer select /monkey/1.0.0 +0ms
  mss:dialer     (1sx1xq) writing multicodec: /monkey/1.0.0 +0ms
  mss:listener   (1xawf5) received ack: /multistream/1.0.0 +3ms
  mss:listener   (1xawf5) adding handler: /monkey/1.0.0 +1ms
# hangs here

@daviddias
Copy link
Member Author

@jacobheun thank you so much for the debugging. I've added you and @pgte to have publish access of libp2p-webrtc-star so that you can unpublish the right version (https://www.npmjs.com/package/libp2p-webrtc-star/access) I'm afraid that with limited time and massive context switch that I might do a poor job of reverting those changes.

@jacobheun
Copy link
Contributor

libp2p-webrtc-star 0.15.1 has been marked as latest and the 0.15.2 changes have been rolled back into master. This issue will be resolved with the release of #203

@ghost ghost removed the status/in-progress In progress label Jun 28, 2018
maschad pushed a commit to maschad/js-libp2p that referenced this issue Jun 21, 2023
maschad pushed a commit to maschad/js-libp2p that referenced this issue Jun 21, 2023
## [5.0.1](libp2p/js-libp2p-websockets@v5.0.0...v5.0.1) (2022-12-08)

### Bug Fixes

* cannot catch EADDRINUSE ([libp2p#198](libp2p/js-libp2p-websockets#198)) ([c7312db](libp2p/js-libp2p-websockets@c7312db)), closes [libp2p#184](libp2p/js-libp2p-websockets#184)

### Dependencies

* **dev:** bump @libp2p/interface-mocks from 7.1.0 to 8.0.2 ([libp2p#199](libp2p/js-libp2p-websockets#199)) ([daff533](libp2p/js-libp2p-websockets@daff533)), closes [libp2p#318](https://github.com/libp2p/js-libp2p-websockets/issues/318) [libp2p#315](https://github.com/libp2p/js-libp2p-websockets/issues/315) [libp2p#313](https://github.com/libp2p/js-libp2p-websockets/issues/313) [libp2p#312](https://github.com/libp2p/js-libp2p-websockets/issues/312)
* **dev:** bump it-all from 1.0.6 to 2.0.0 ([libp2p#193](libp2p/js-libp2p-websockets#193)) ([6213f8f](libp2p/js-libp2p-websockets@6213f8f)), closes [libp2p#28](libp2p/js-libp2p-websockets#28) [libp2p#28](libp2p/js-libp2p-websockets#28) [libp2p#27](libp2p/js-libp2p-websockets#27) [libp2p#24](libp2p/js-libp2p-websockets#24)
* **dev:** bump it-drain from 1.0.5 to 2.0.0 ([libp2p#191](libp2p/js-libp2p-websockets#191)) ([e549691](libp2p/js-libp2p-websockets@e549691)), closes [libp2p#28](libp2p/js-libp2p-websockets#28) [libp2p#28](libp2p/js-libp2p-websockets#28) [libp2p#27](libp2p/js-libp2p-websockets#27) [libp2p#24](libp2p/js-libp2p-websockets#24)
* **dev:** bump it-take from 1.0.2 to 2.0.0 ([libp2p#192](libp2p/js-libp2p-websockets#192)) ([4c037fc](libp2p/js-libp2p-websockets@4c037fc)), closes [libp2p#28](libp2p/js-libp2p-websockets#28)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/expert Having worked on the specific codebase is important kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

2 participants