Unit test for reproduction of issue scenario #6515 #6644
Conversation
|
I understand the use case. |
|
Hey Daniel! Thanks for the update. I think you are correct in that adding this event as something that we can use to react its a feature, yes. But I feel the behavior on the RxDB side is still kinda broken, I would argue. You see, from RxDB perspective, if the websocket connection fails or gets dropped, a new one is created to re-stablish communication. I would argue this scenario is one that should cause the same behavior as when a GraphQL subscription gets dropped. |
|
Dropped subscriptions that reconnect could lead to missed events on the client that happen during this time. Please consider that case when implementing. |
|
Hi Daniel, I have started coding this feature and realized that this was solved in the PR #6598. With the exposed wsoptions it is possible to listen to the closed events and reconnect. So I think this issue can be closed. |
This PR contains:
Unit test for reproduction of issue scenario #6515
Describe the problem you have without this PR
Today there is no error or event published when a client loses its websocket connection. Then we can't know and try to fix the problem, and that user doesn't get live updates anymore.