Handle messages not bridged

[erdnaxeli]

A common pitfall with matrix bridges is that your message is sent to matrix but not actually bridged to the third party network. It's a pitty, as you need to really trust the code but have no way to ensure your message is actually bridged. For example, I developed a stupid irc bot which just reply on message just to be able to test my IRC bridge instance.

This a complex problem that cannot be totally solved at the bridge level, but I think we could help a bit the user. Obviously we can just add some retry, but I don't think it's a good solution. Imagine this:

• time X: I send a message A, which is not bridged due to some error
• time X+1: A user from the third party network send a message B, which is correctly bridged
• time X+2: After some retries, my message A is finally bridged

Now we are in the situation where from my side I see the message A then B, but the users on the third party network see B then A.

That's why I think the retry duration should be very short (something like one minute), and the retries should stop as soon as we receive a message from the third party network.

The thing is to notify the user that the message was not bridged. For this, I see two solution:

1. The bridge's bot deletes the message from the matrix room, and notify the user in the admin room
2. The bridge's bot reply to the message (using matrix replies), to warn the user "this message was not sended" (to distinguish bot's messages, notify may be used).

The solution 1 keeps a clean room's history , but is not very user friendly and force the user to go to another room to know what happened. The second solution would be more easier to understand by the user, but will add some garbage to the room's history.

https://github.com/tulir/mautrix-whatsapp/blob/2ec6ad242c2c03961aa689e01a24ab7970fd4279/portal.go#L788

[ptman]

Reactions or some sort of annotations could maybe also be used: matrix-org/matrix-spec-proposals#441

[tulir]

Aggregations or custom EDUs would be nice as a "this message has been bridged" acknowledgement, but I'm guessing the spec/synapse impl will take quite a while still.

I think either the whatsapp web servers or go-whatsapp actually does retry sending if the phone is disconnected at the time. The bridge probably needs to handle cases where the connection fails completely (e.g. another web session is active)

[krombel]

WhatsApp does not ensure the same order on all distributed devices. So the mentioned scenario occurs as well the case when $device is offline.
For the bridge I would therefore "just" implement some retry loop until the message got sent and don't bother with correct ordering

[erdnaxeli]

WhatsApp does not ensure the same order on all distributed devices. So the mentioned scenario occurs as well the case when $device is offline.

Yeah and I hate when it happens. It is a source of confusion in the discussion.

You need timeout. Retrying after some minutes is non sens imho.

[tulir]

I think I added messages corresponding to that error log at some point.