-
Notifications
You must be signed in to change notification settings - Fork 87
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
Cannot read properties of undefined (reading 'id') #6050
Comments
This is odd. I have not been able to reproduce it locally nor on the instance in question yet. |
I tried to reproduce this in various ways:
I still failed to reproduce it. What I did run into was a situation where |
Looking at the code this is probably caused by the list of sessions not including any with the current id. I see two possible causes:
|
URLs seem mostly from files, collectives is just a low amount, top most is a read only share (from the app tutorials), but could just be due to the amout of people browsing it. |
Interestingly browsers are just chromium based ones |
uuuhhh... we have this routine to clean up old sessions during the request. That happens after auth. So maybe one can still authenticate with a session and then have it cleaned up. update: but we only do this during create and close. Create does not require any auth anyway - so maybe this happens when automatically reconnecting and the old session is still around somehow. Since the last update we don't clear the sync service anymore if i remember correctly. |
I was able to trigger an inconsistent state by switching the network off and on again. After a while yjs will attempt to reopen the websocket, calling SyncService.open which fails to open a new connection but still continues. Afterwards sync services This happens a few times until the editor shows the reconnect button. I suspect it's basically the polling backend continuing in the backend. |
I also couldn't trigger the issue but I noticed when opening a read only link and keeping the browser running for a while we sometimes have additional create requests without a previous close |
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com>
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com>
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com> [skip ci]
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com>
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com>
Do not attempt to create a new connection if there already is one and it is not closed. If no messages are received for 30 seconds yjs will open a new websocket. Since we do not close the connection anymore from the websocket polyfill we also do not need to open it. If the network connection has gone down creating a new connection will fail anyway. Once it comes back we will know if the session is still valid. Then we can either continue using it or reconnect. This is part of #6050. Signed-off-by: Max <max@nextcloud.com>
Sentry reported a quite frequent console error, that only seems there since "29.0.4 RC1"
https://nextcloud-gmbh.sentry.io/share/issue/0d2e881a7a144773a4460df9cb99acd1/
The text was updated successfully, but these errors were encountered: