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

Issue when peer got reconnected after disconnected by using webrtc provider #24

Open
abdashaffan opened this issue May 10, 2021 · 6 comments
Assignees
Labels

Comments

@abdashaffan
Copy link

abdashaffan commented May 10, 2021

Describe the bug
I’m currently trying to run two instances of this demo (but changed the provider to webrtc) on my local (using two different port). When one instance (user1) got disconnected and then got reconnected again, at first both content from user1 and user will get synced again.

But when user1 tries to add new content, user2 will not receive the update from user1 anymore, but update user2 will still be received by user1 (the updates will become one-direction only).

But this issue didn’t occur when I tried this by using websocket provider. Is there some extra configuration needed to make sure y-webrtc can handle this scenario? or is this a bug on y-webrtc? please let me know if I’m missing something or if you need more information.

To Reproduce

  1. Clone this example, change the provider from websocket to webrtc, like this:
  // const provider = new WebsocketProvider('wss://demos.yjs.dev', 'prosemirror-demo', ydoc) #commented
  const provider = new WebrtcProvider('demo-ywebrtc', ydoc);
  1. Run two instances of the example on your local
  2. Make one of the instances offline
  3. Make that instance online again
  4. Now changes from that instance won't get synced with other instances anymore, but changes from other instances will still get synced with that instance.

Expected behavior
The reconnected instance's update will get propagated to other peers as usual.

Screenshots
Not a screenshot, but I’ve created a short screencast to reproduce the issue in case my explanation is not clear enough.

Environment Information

Edit: Still got the same issue on [email protected]

Additional context
I don't know if this is relevant, but this issue is also occurring on a real connection test (using two ubuntu VM connected by VirtualBox's default NAT network config, and by making one of the VM offline).

@abdashaffan
Copy link
Author

Update: So I've done more trials using VM and turns out that sometimes the sync workflow works correctly, but sometimes it doesn't.

@abdashaffan
Copy link
Author

hi, any update about this issue?

@nowakkamil
Copy link

I have also experienced this issue. What's more interesting, I'm using WebrtcProvider in conjunction with ProseMirror, and the cursor position won't get propagated after the connection has been lost and reestablished again.

@clibu
Copy link

clibu commented Jun 27, 2021

I am seeing similar issues. I have an app running on Edge and Chrome on one Win10 PC and Chrome on a Chromebook. All are using the WebRTC provider with the default signaling servers. And the IndexedDb provider.

Initially an update on a Browser was seen on the others, however now updates on Chrome on Win10 aren't seen on the other two Browsers. However the other two Browsers see each others changes. I've restarted the Win10 PC and this made no difference.

I've enabled webrtc logging and when I do an update on the Chrome + Win10 PC nothing is logged on the other two Browsers. Updates on the other two Browsers do show log entries on the other Browser.

Opening a second Chrome Tab in a second Chrome Window on the Win10 PC does show updates, but only from the other Win10 Chrome Tab.

If I delete all YJS content and .clearData() from indexeddb then all browsers communicate and update correctly again.

@joel-simon
Copy link

Any update on this?

@dmonad
Copy link
Member

dmonad commented Nov 16, 2021

Oh I think this has been fixed in the last PR. Can you please test the latest version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants