-
Notifications
You must be signed in to change notification settings - Fork 202
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
/sync returns outdated OTK counts #17491
Comments
We usually upload OTK at the end of a sync request and before doing a new sync request no? Not sure how Notification Sync vs Normal Sync might impact that. Or maye with the new sliding sync though |
I can confirm that from a fresh login with simplified sliding sync (EXA emulator on local synapse), that there are 2 consecutive upload_keys, publishing 100 OTK. After first call
After second call
but this is before any sync call. The first upload has the device keys The second one only has otks + a fallback key client logs
And
I need to retry on a clean emulator, surprised to see that the tracing says |
Ok so I got what is tirggering this bg just after login. On account creation the sdk create the olm_account and uploads the key. Around the same time a sync is started. This is the race: The sdk receives the device keys upload response, and call Meanwhile the initial sync response is handled, As a consequence the sdk thinks all the keys have been used |
Typically, the way that
/sync
works is this:since
token, callcurrent_sync_for_user
to generate a sync response and new sync token.This means that, if the user is in no active rooms, the entire sync response and token are 30 seconds old.
This is particularly bad if the client uploads some OTKs in that 30-second slot, since the
/sync
response will include the OTK count from before the upload request.The upshot of all this is that most clients end up uploading 100 keys when really they only meant to upload 50.
The text was updated successfully, but these errors were encountered: