We currently have a problem with the integration of an error handler for the SyncManager. Following the example from the documentation, we have a similar implementation:
let app = App(id: YOUR_APP_SERVICES_APP_ID)
app.syncManager.errorHandler = { error, session in
// handle error
}
When a realmUser is deleted on the backend I expect a corresponding callback in this error handler. But this does not happen as long as the app is running. I only get a .clientSessionError() via this error handler after restarting the app, which is of course much too late.
So my question is:
Am I subject to a comprehension problem here, or am I doing something wrong? How do I get real-time information from the backend that the user I am currently logged in with on the client no longer exists?
This is the expected behaviour: while a session is open, there are no further checks on the authorization, at this time. As you’ve found yourself, opening a new session does that check, and raises the error.
Have you tried to Revoke All Sessions, and Disable the User first?
Thanks @Paolo_Manna!
Expected behaviour? Oh, that surprises me a bit.
Okay, maybe I asked the question a little misleadingly. It’s not just about deleting a realmUser in the backend, but in general. In our software, it can also be deleted programmatically by an action triggered by the client (on device A). If this user (who has just been deleted) is currently logged in on device B, we should notice this immediately and react. We have understood that the SyncManager is responsible for informing the client for exactly such scenarios.
Does this mean that we do not receive any callback from the backend for such scenarios?
In general: What is the best way to react immediately to sync errors?
Yes, your scenario is unusual, however, as stated above, a valid session isn’t interrupted at this time, so the second client (that, from the Device Sync point of view, has a separate state) isn’t typically notified.
A possible workaround is the use of Custom Data: if the custom user data is either modified or removed, the second client will receive an (automatic) disconnection, and , if the user is deleted, on the following (automatic) reconnection it will be rejected.
I’ve discussed this with Engineering, and they’ve stated that checking whether a user is active is possible, but at a periodic pace, as that has a performance cost: they’ll evaluate the possibility, though.