-
Notifications
You must be signed in to change notification settings - Fork 4
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
Not re-sending data after user ID changes #11
Comments
Not sure. I have not tested that case. Maybe add a test case PR. I would expect it is the same as stop and then create, which should be handled by the current logic. But it is very possible that it is something special which was not patched. |
I have investigated further and confirm that this is an issue that will sometimes cause publication data to be lost. It should be fixed ASAP. During the execution of _setUserId(), the _isSending flag is set false. This instructs the sendAdded(), sendChanged() & sendRemoved() methods to not send messages to the client over the websocket - they will simply be discarded. At the end of _setUserId(), _isSending is re-enabled and diffCollectionViews() does a diff of the saved state of the collectionView (before _setUserId() was called) with the current state, and then triggers the sendAdded() & sendRemoved() methods to propagate the differences to the client. But diffCollectionViews() will fail to work as intended for the publish endpoints that have disableMergebox() activated because the current collectionView will be empty for every document id in their published collection. |
Interesting. Feel free to make a PR with a fix and test. |
@mitar I'm happy to financially sponsor the resolution of this issue. I have sent you an email. |
Hello @mitar ,
I have been testing the disable mergebox functionality with vlasky:mysql .
I am seeing unexpected behaviour when an unauthenticated user subscribes to a publication and then logs in, i.e. this.userid changes on the server side.
As you know, what normally happens when userid changes on the server side is that all subscriptions are temporarily paused, then the publish functions are re-run, any data changes are filtered through the mergebox, then subscriptions are re-enabled.
This step is necessary to handle changes in data visibility depending on what a given user ID is intended to be able to see from that publication.
But when the merge box is disabled, I expect the publication to resend all the data in the published collection after the user id changes.
During my tests, I did not see this happening.
Have I found an unhandled case in the server side logic or have I misunderstood something?
The text was updated successfully, but these errors were encountered: