-
Notifications
You must be signed in to change notification settings - Fork 37
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
account_data returned by /_matrix/client/unstable/org.matrix.msc3575/sync
are sometimes inconsistent
#189
Comments
/_matrix/client/unstable/org.matrix.msc3575/sync
are sometimes inconsistent
Given the extra sliding sync variable in the middle of all of this, it seems like the first thing that would need to be eliminated. I'm unable to transfer this to https://github.com/matrix-org/sliding-sync but perhaps @DMRobertson has access? |
First step would be for us to reproduce this with some kind of test on the proxy side. Lines of investigation:
this sounds wrong. Is the proxy not correctly deduping or merging account data updates here? |
Account data updates have no ID so I suppose it's possible for them to step on each other if you have >1 device? In the same way that typing notifs can? |
@kegsay I have made a few more tests and can confirm that the problem does not occur if there is only one session on EIX. Step to reproduce :
|
#237 would mostly address this, as it will cause the following:
In other words it will A) stop multiple push rules coming through in the response and B) ensure you don't get told the same data twice. However, it does nothing to help guard against flickering (where it temporarily resets back to the old value then advances forward) as the proxy has no way to uniquely identify versions of the event being updated. |
Precise timings in the logs:
So there was a latency gap of ~200ms on one poller, which caused it to revert briefly. |
This isn't resolved yet because flickering can still happen. This issue is now tracking the resolution of this, which dmr hints at:
race being:
The problem is there is no bulk GET endpoint for account data, so if "new piece of acct data" is a brand new unseen Data structure wise, if each poller has a |
Empirically this didn't seem to be a blocker. |
@manuroe please can you advise on the flicker question as per above? |
I am aligned with @kegsay on "changing notification settings is probably not something we do every day". The current solution is good enough. Let's fix it properly in the next gen ;) |
Description
I see a strange behaviour when updating a push rule using the push API
/_matrix/client/v3/pushrules
Each request (
PUT
orDELETE
) triggers a sync response but sometimes the response is incorrect.Here, after creating a
ROOM
rule and deleting anOVERRIDE
rule, I have 6 sync responses with different values inaccount_data
.Sometimes I have the
m.push_rules
more than once (#70, matrix-org/synapse#73), and sometimes and old value is coming back temporarily (#71 is up-to-date to date, matrix-org/synapse#75 contains the deleted rule)Here are the requests visibles in the attached Proxyman log:
ElementX_06-28-2023-16-02-36_ss_push_rules.proxymanlogv2.zip
(same session exported in postman format)
ElementX_06-28-2023-16-33-17_postman.json.zip
Steps to reproduce
Homeserver
matrix.org
Synapse Version
1.86.0
Installation Method
I don't know
Database
I don't know
Workers
I don't know
Platform
I don't know
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response
The text was updated successfully, but these errors were encountered: