Closed jmartinesp closed 1 month ago
Hi there, let me know if I can do anything to support debugging this. If you need access to the actual content being returned (or to the raw database), give me a shoutout. Happy to give you an access token or postgres access. Thanks in advance.
Been randomly poking in some slidingsync tables:
select event_stream_ordering from sliding_sync_membership_snapshots WHERE event_stream_ordering<=0;
event_stream_ordering
-98673
-67914
-44846
-38983
-14132
Are there supposed to be negative values in here, for instance? (I have 1016 positive rows)
And just in case they are not supposed to be negative (and that is where I will stop poking in the dark). After truncating all slidingsync* tables, this table is being recreated with those same negative numbers by synapse 1.115, so it is not some historical garbage. (I know that the tables are currently repopiulated when empty, which will not work in future synapse versions).
Err, the negative event_stream_ordering value of -67914 in my db corresponds to the wrong value as captured by the SDK log, so there seems to be an impedance mismatch on what is sent and what is expected.
@spaetz Side note: thanks for helping and for your patience!
You are welcome, it is in my own interest. BTW, great talk of yours today. You hiked all those peaks yourself? :-)
Negative stream ordering corresponds to backfilled events IIRC.
This is odd. As clokep says, negative stream ordering happens when we backfill events. However, these stream orderings are for the membership events of local users, so how did they end up being backfilled?!
@spaetz did you by any chance delete the room? That might explain why local users membership events are being backfilled.
Can you also run:
SELECT membership, sender == user_id, event_stream_ordering FROM sliding_sync_membership_snapshots
WHERE event_stream_ordering<=0;
SELECT membership, sender=user_id, event_stream_ordering FROM sliding_sync_membership_snapshots WHERE event_stream_ordering<=0;
membership | ?column? | event_stream_ordering
------------+----------+-----------------------
leave | t | -38983
leave | t | -14132
leave | t | -98673
leave | t | -44846
join | t | -67914
(5 Zeilen)
The last row is room #community-moderation-effort-bl:neko.dev (that I am actually still a member of). But I have powerlevel 0 (not allowed to write in the room).
I probably joined and left and rejoined that room in the history of the user, but I certainly have joined the room using this very synapse server.
Thanks @spaetz, that was useful.
Hopefully fixed by: https://github.com/element-hq/synapse/pull/17748
Just to confirm that 1.116rc1 has fixed the issue and SSS syncs now just fine with EXA!
Description
We received a report from a user of Element X Android (@spaetz in here, if I'm not mistaken) where he couldn't get the app to work with SSS at all with one account in his homeserver but it worked fine with different one in the same HS, the cause seemed to be the client was cancelling each
/sync
request before the HS finished sending it (lots of200!
status codes for/sync
requests).After some debugging, we found these errors in the logs of the SDK:
We can deduce some field has an invalid format, where some positive number was expected but we receive a negative one, and in the same logs we can find the same error happening at different indexes inside the
/sync
response, so it's a value that's repeated several times in the responses:Sadly, we don't have the response contents to check which field is causing this issue.
Steps to reproduce
/sync
request will fail.Homeserver
https://sspaeth.de/
Synapse Version
0.115.0
Installation Method
I don't know
Database
-
Workers
I don't know
Platform
Debian
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response