Kegan Dougal

If this is a deserialisation error, `/sync` won't help this. We need to preserve the user's DM information if we fail, not replace it.

> I guess /sync will apply only valid events, so events that can be deserialized, This isn't true. The proxy does need to inspect some events like the `m.direct` account...

Related: https://github.com/matrix-org/synapse/issues/13704

Specficially this would in the common case cause a single UTD, as the act of sending the encrypted message would merge the forks and cause S2 to arrive on the...

@erikjohnston would it help at all that at least for SSS we only care about returning the current state? We may not be able to fix it for sync v2...

I've seen this happen again but this time between element.io matrix.org, where the client on element.io saw in response to /keys/claim: `"matrix.org": Object {"message": String("Failed to send request: HttpResponseException: 429:...

https://github.com/matrix-org/matrix-spec-proposals/pull/4081 would be a solution to this because then the sending server could just serve up the fallback key if it cannot talk to the recipient server.

Another one, element.io matrix.org failing with a different error: `failures={"matrix.org": Object {"status": Number(503), "message": String("Failed to send request: TimeoutError: Timed out after 10s")}}`

This happened again in a large E2EE room. The failure mode was subtly different though because `/keys/claim` did eventually succeed for a 2nd+ message, so the error message was `The...

Should come for free if we use testcontainers https://github.com/matrix-org/complement/issues/655