You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Event got sent but not synced back down everywhere #9424
The client that sent the event (element desktop) and my dekstop hydrogen running alongside did not get the event from sync.
On element desktop the event was black (e.g. sent) but stuck to the bottom of the room, and on hydrogen I check the storage and it showed that there was no limited sync for that room around those messages, and there is no trace of that event anywhere.
When opening my phone hydrogen an hour or so later, the event was synced down to it in the correct order.
At least T3chguy and Ryan did receive the event in the correct order.
changed the title [-]Event got sent but not synced back down to some of own clients[/-][+]Event got sent but not synced back down to some devices[/+]on Mar 18, 2021
changed the title [-]Event got sent but not synced back down to some devices[/-][+]Event got sent but not synced back down everywhere[/+]on Mar 18, 2021
@callahad@anoadragon453 I renamed this ticket as #9624 (which was marked as a dupe) is about the recipient and not the sender not receiving the message. FYI if this changes the severity of the bug.
Just an update: This is on our radar, but we expect it to be a pretty big yak to shave, so it's currently deferred until we can wrap up some other hairy problems 🐃
@Fizzadar Hi; thanks for taking some time to write this up.
I'm still unfamiliar with MSC2716, but I think it may be useful to know the structure of the DAG to figure out what's going on here.
Is there any chance you'd be able to run the following?:
SELECT stream_ordering, type, state_key, event_id, (ej.json::json)->'prev_events'AS prev_events FROM events
LEFT JOIN event_json AS ej USING (event_id)
WHEREevents.room_id='!SjekxtmsBigrUMcMkX:beeper-dev.com'ORDER BY stream_ordering ASC;
If the room has been used more since your last message, feel free to trim it to the range that was there previously.
@Fizzadar Oooh, interesting (maybe, likely need to think about it! whilst reading the batch send MSC!).
What I find interesting is that there are multiple events with no prev_events (which is what I expect from the batch sending stuff) but no later events have more than 1, to merge the forks together. (Only making remarks so I can keep track of this; not sure if that's important or not.)
Are those all the events in the room; if not, are there any that merge later on?
I wonder if it makes sense to split out our line of discussion, because presumably this is something to do with batch_send and not whatever the original issue was back in Feb 2021.
Given the complexity of how Synapse's implementation ofMSC2716 interacts with the room DAG, it does appear likely that the bug in your case @bradtgmurray is related to batch_send code - specifically the /sync bit of it. Moving and tackling this case in a separate issue would be ideal.
I see that mautrix/whatsapp#463 has been linked to this issue though - do you find that backfilling the room works to recover the missing event in all cases?
@richvdh I agree - this issue has become a bit of a mishmash of related problems, with an awful lot of old comments to read before hitting content relevant to today's ecosystem.
Closing this issue as it looks to have run its course. Please file a new issue if you have one; potentially linking this one if relevant.
Activity
BillCarsonFr commentedon Mar 16, 2021
we have also several report of that on android
https://github.com/matrix-org/element-android-rageshakes/issues/20724
https://github.com/matrix-org/element-android-rageshakes/issues/20672
https://github.com/matrix-org/element-android-rageshakes/issues/20578
I also experienced it on other client (web)
Also this issue element-hq/element-android#516
BillCarsonFr commentedon Mar 16, 2021
#9624
[-]Event got sent but not synced back down to some of own clients[/-][+]Event got sent but not synced back down to some devices[/+][-]Event got sent but not synced back down to some devices[/-][+]Event got sent but not synced back down everywhere[/+]bwindels commentedon Mar 18, 2021
@callahad @anoadragon453 I renamed this ticket as #9624 (which was marked as a dupe) is about the recipient and not the sender not receiving the message. FYI if this changes the severity of the bug.
callahad commentedon Mar 24, 2021
Just an update: This is on our radar, but we expect it to be a pretty big yak to shave, so it's currently deferred until we can wrap up some other hairy problems 🐃
richvdh commentedon Jul 12, 2021
Matthew reported another instance of this today. Link and details for internal users at https://github.com/matrix-org/element-web-rageshakes/issues/5808
anoadragon453 commentedon Aug 12, 2021
And another set by Matthew on Aug 10:
erikjohnston commentedon Aug 12, 2021
We should add some more logs to try and track down where the event is going missing. I'd probably do something like:
_get_rooms_changed)_generate_room_entrycall, tagging it with room IDetc. The idea being that hopefully we'll be able to see if the missing event is pulled out of the DB and if so where we drop it (if we ever do).
Add logging to help debug #9424 (#10704)
ara4n commentedon Sep 7, 2021
And another just now...
ara4n commentedon Sep 9, 2021
...and again...
32 remaining items
Run message history backfill after creating all the rooms
reivilibre commentedon Mar 17, 2022
@Fizzadar Hi; thanks for taking some time to write this up.
I'm still unfamiliar with MSC2716, but I think it may be useful to know the structure of the DAG to figure out what's going on here.
Is there any chance you'd be able to run the following?:
If the room has been used more since your last message, feel free to trim it to the range that was there previously.
Fizzadar commentedon Mar 17, 2022
@reivilibre thanks for looking into this; query results:
reivilibre commentedon Mar 17, 2022
@Fizzadar Oooh, interesting (maybe, likely need to think about it! whilst reading the batch send MSC!).
What I find interesting is that there are multiple events with no
prev_events(which is what I expect from the batch sending stuff) but no later events have more than 1, to merge the forks together. (Only making remarks so I can keep track of this; not sure if that's important or not.)Are those all the events in the room; if not, are there any that merge later on?
Fizzadar commentedon Mar 17, 2022
@reivilibre that's everything in the room! We left it alone after replicating the issue in case this data is useful :)
bradtgmurray commentedon Mar 22, 2022
I wonder if it makes sense to split out our line of discussion, because presumably this is something to do with batch_send and not whatever the original issue was back in Feb 2021.
Run message history backfill after creating all the rooms
anoadragon453 commentedon Mar 23, 2022
Given the complexity of how Synapse's implementation ofMSC2716 interacts with the room DAG, it does appear likely that the bug in your case @bradtgmurray is related to batch_send code - specifically the /sync bit of it. Moving and tackling this case in a separate issue would be ideal.
I see that mautrix/whatsapp#463 has been linked to this issue though - do you find that backfilling the room works to recover the missing event in all cases?
bradtgmurray commentedon Mar 23, 2022
The whatsapp PR is just us trying things attempting to work around the issue, haven't gotten to the bottom of it yet.
Do you know if the DAG we posted above looks correct to you?
Fizzadar commentedon Mar 24, 2022
I've split out relevant parts into a new issue #12281, let's continue discussions there.
richvdh commentedon May 19, 2022
I'm not really sure what's going on here. It seems like there are:
MultiWriterIdGenerator#11045In any case, there is probably more than one bug here, and lumping further reports into a single issue is likely to cause confusion.
As such, can this be closed? I don't think there's any useful context here.
anoadragon453 commentedon May 19, 2022
@richvdh I agree - this issue has become a bit of a mishmash of related problems, with an awful lot of old comments to read before hitting content relevant to today's ecosystem.
Closing this issue as it looks to have run its course. Please file a new issue if you have one; potentially linking this one if relevant.
Pullup ticket #6538 - requested by gdt