sometimes the sending device doesn't seem to know about some recipients in the room

[richvdh]

... which obviously leads to UISIs. That's recipient users, not devices

[richvdh]

It would be tempting to blame this on federation-style problems like matrix-org/synapse#1953, except that I've seen this between two users on the same HS (https://github.com/matrix-org/riot-web-rageshakes/issues/73).

It could be the client getting the room state out-of-sync due to rollback on state resolution, but it seems to affect @DatseMultimedia:matrix.org in megolm test, who has been a member there since 2016-12-12, so this seems surprising.

IOW: currently I'm mystified.

[richvdh]

https://github.com/matrix-org/riot-web-rageshakes/issues/35 is another instance of a sender not knowing DatseMultimedia was a member - in that case the sender was on android, @zottel:matrix.zottel.net.

[lampholder]

@richvdh I've added fairly arbitrary priority/severity - feel free to adjust if you see fit :)

[richvdh]

https://github.com/matrix-org/riot-android-rageshakes/issues/62 is DatseMultimedia failing to receive from zottel again

[richvdh]

https://github.com/matrix-org/riot-web-rageshakes/issues/130 shows @uhoreg:matrix.org failing to receive from @realitygaps:chat.weho.st (also riot-web) under similar circumstances (realitygaps' device appears not to know uhoreg is a member of the room). Again, it could be due to an artifact of state resolution, but uhoreg has been a member of the room for a long time.

A thought: perhaps we could include a list of "users we know about" when sending the megolm events, so that we can double-check it on the server side.

[richvdh]

element-hq/riot-android#1507 is @erdnaxeli:cervoi.se (a recent joiner) failing to receive from @matrixcoffee

[richvdh]

I suspect matrix-org/synapse#2418 is a cause of a bunch of these, though it doesn't explain all of them.

[ara4n]

worth noting that matrix-org/synapse#2418 is now fixed. i personally haven't spotted this one in my UISI voyages; i wonder if the remainder are state resets...

[richvdh]

It doesn't require a full-on state reset for a client's list of room members to get out of sync with the server's, because normal state resolution can lead to divergence between server and client, as per https://github.com/matrix-org/synapse/issues/2735.

Anyway, yes, any remaining cases of this are probably an artifact of https://github.com/matrix-org/synapse/issues/2735, but should we keep this open to track it from the client side (with potential workarounds such as that mentioned in #3846 (comment)) ?

[ara4n]

From memory, I think https://github.com/matrix-org/riot-web-rageshakes/issues/1973 and https://github.com/matrix-org/riot-web-rageshakes/issues/1974 is an instance of this (where Vincent's client didn't encrypt for Valere at all, despite being in the same room)

[richvdh]

From memory, I think matrix-org/element-web-rageshakes#1973 and matrix-org/element-web-rageshakes#1974 is an instance of this (where Vincent's client didn't encrypt for Valere at all, despite being in the same room)

for more details on this, see #11502

[richvdh]

see also: #14929

[ghost]

Backlog Triage:
Since we're still seeing UTD issues I assume this issue is still valid. @richvdh can you please confirm?

[richvdh]

I don't think this issue is providing any value nowadays. It doesn't seem to have identified any consistent pattern, and if we had similar problems nowadays we'd probably investigate from first principles. Closing accordingly.