-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
'peers' event on on SignalingConn emits 'added' peer from peer's close event #23
Comments
When a client disconnects, it automatically tries to reconnnect. Are you sure that the client is disconnected when |
Yes. When I review y-webrtc for the close, (this.peer.on('close', () =>...) the last line is announceSignalingInfo(room) which triggerS:
there's the debugs you're seeing. 'true' is conn.connected. So on close, it's announcing signically messages, even though it's closing. My naive understanding suggests it shouldn't be announcing or, this shouldn't say 'added' from the message :
|
There are three types of connections. 1. There are WebRTC connections. The line you mentioned |
alright, what I'm seeing:
the announceSignalingInfo call triggers the announcement and the second client gets a 'peers' notification as the peer being added. It's possible it's a race condition since I'm just doing it locally between two browsers or it's something stranger with the devserver updating. |
How do you close the connection to the remote client? |
refresh the browser -> close is triggered If it was re-logging in, we'd have a different peerId, but the same peer ID shows up on the second client. That's the log that's shown on the second browser window, which I retested just so:
|
This is probably the reason. A devserver often duplicates created objects. Sorry, it is impossible for me to debug this issue. Unless you provide a step-by-step example for how I can reproduce this (without some react dev-server setup) I can't help you. Can you maybe create a simple project (maybe fork https://github.com/yjs/yjs-demos) and describe the steps to reproduce this issue? |
it appears to be chrome specific. I upgraded the demo here: https://github.com/disarticulate/y-webrtc/tree/master/demo Reproduce:
You may want to use the standard SimplePeer if you think I did something untoward to it. I'll comment on the rest of that code in the other issue I've got open #20 |
Checklist
Describe the bug
generates an announcement which triggers remote peers:
message peers then says this peer was added which is not what's happening, as peer is closing.
To Reproduce
Steps to reproduce the behavior:
Open two browsers with peers connected. Listen to room.provider.peers for 'peers' and you'll see the event.removed shows the peerId, but then another events.added shows the peer added again
Expected behavior
When a peer closes, it should not generate a peers event that has the peer added.
Screenshots
debug:
Environment Information
Version 89.0.4389.82 (Official Build) snap (64-bit)
"y-webrtc": "^10.1.7"
"y-protocols": "^1.0.4",
"yjs": "^13.5.2"
The text was updated successfully, but these errors were encountered: