Client API: mutex on (user_id, room_id)

[matrixbot]

This issue was originally created by @kegsay at https://github.com/matrix-org/dendrite/issues/903.

We should be able to make some guarantees about message ordering from a single client, insofar that if you send 1,2,3,4,5 it should be in the DAG as 1,2,3,4,5 without forks created by your own messages. We can do this by locking for a given room/user tuple, which assumes we don't run multiple client APIs which aren't sticky on the user.

This may be a cause of SyTest flakiness, as it rapidly sends events.

[matrixbot]

This comment was originally posted by @prateek2211 at https://github.com/matrix-org/dendrite/issues/903#issuecomment-598351724.

I am not clear about what issues says, but as far as I understood, there shouldn't be race between goroutines sending events to roomserver . So for that wouldn't adding lock and unlock inside send messages routines work ?

[matrixbot]

This comment was originally posted by @anandv96 at https://github.com/matrix-org/dendrite/issues/903#issuecomment-640206066.

Hello, I would like to work on this issue. I'm also unsure of what exactly needs to be done. I understand that with messages being sent very rapidly, there is a possibility that a newer message would be entered into the room than an older one.

Like @prateek2211 mentioned, shouldn't this be addressed at the place where the clientAPI sends the messages to the roomserver? (maybe in clientapi/producers/roomserver.go?)

[matrixbot]

This comment was originally posted by @kegsay at https://github.com/matrix-org/dendrite/issues/903#issuecomment-640487761.

Yup

[matrixbot]

This comment was originally posted by @kegsay at https://github.com/matrix-org/dendrite/issues/903#issuecomment-674170337.

Related: https://github.com/matrix-org/dendrite/issues/547 which has a mutex per room on the roomserver.