-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
key query causes device list updates over /sync in a loop #9613
Comments
https://spec.matrix.org/unstable/client-server-api/#tracking-the-device-list-for-a-user gives some useful information as to how this should play out. Indeed I could see a loop occurring if Synapse keeps adding Do you see multiple instances of the same device being updated in the In synapse/synapse/handlers/device.py Lines 854 to 948 in 0a00b7f
I'm not sure how the Element clients are currently handling this without hitting the same failure mode. |
I'm not sure, how I would check, if multiple instances of the same device get updated, do you have some hints there? I have the following output for that user:
The high stream ids seem to get updated at the same time and are increasing rapidly. Maybe you can give me some guidance on how to query the data you need? |
Actually that tells me what I need to know, thanks 🙂 So the stream IDs are increasing with every update, which causes I'm currently waiting to hear back from the client devs to see if they know something I don't. Out of curiosity though, do you experience the same looping behaviour if you request the keys of a remote Synapse user? |
No, it is actually just that construct user, so should I just file a construct issue in that case? Because this suggests the construct server is responding with invalid data to the query, right? |
Possibly, however Synapse does indeed look to be updating devices unnecessarily. Funnily enough we just had a PR that fixed that: #9634 It focuses on cross-signing keys, but includes general device list updates as well. If you're able to, you may want to attempt with that code merged and see if the problem persists. |
Can I just apply that PR as a patch cleanly on the latest RC and not expect things to break, even if I remove it again? Because then it would be very easy to test for me. |
Seems to be fixed by #9634. I'm guessing that will be in 1.31 then? Or is that picked into 1.30? |
@deepbluev7 It will land in v1.31.0 yeah. I'll write here if that changes 🙂 Thanks for reporting regardless. Let us know if you get anything back from the Conduit side 🙂 |
Okay, so feedback from the construct side: It seems like this was caused by partially disabling e2ee on the construct side or some other temporary e2ee experiments, that then caused fallout after they were disabled. So there certainly was something happening on the construct side, but it is probably good, that synapse won't freak out over that anymore. Thank you both again for the fast response! I'm going to use the patch until it is included in a release for now. :3 |
Preface: This may not actually be a synapse bug, but a client bug or a construct bug, but I'm taking a guess, that this is an issue in synapse.
Description
So, I have been experiencing a high load of master key queries on my database:
This seems to have come from the following loop:
@jason:test.zemos.net
/_matrix/client/r0/keys/query
GET matrix://test.zemos.net/_matrix/federation/v1/user/devices/%40jason%3Atest.zemos.net
Steps to reproduce
I don't think there is a good way to reproduce it? I broke the loop now by suppressing the device key queries once, so maybe it can be restarted by sending another query.
I think synapse should not send a device list update to the client here, if the remote query doesn't return a different result.
Logs:
Note: these are just from the master process, but the federation reader shows no relevant incoming transactions.
filtered by zemos:
Version information
If not matrix.org: neko.dev
Version: 1.29.0
Install method: custom ebuild
The text was updated successfully, but these errors were encountered: