Please fix that element won't ask another element user for resending/redoing encryption if we're both connected

[ell1e]

Steps to reproduce

1. We're both chatting in an encrypted chat. Suddenly I'm seeing this:

2. We continue talking, the next messages work again, but here comes the catch:
3. As we talk, evidently have a working connection with working encryption again, the above error messages do not recover with the proper message contents

Outcome

What did you expect?

If a secure encryption is established again with a sender client that has just minutes ago sent me messages from that same device and something about the keys failed, the protocol absolutely should fetch those again.

What happened instead?

Doesn't work, I just stare at errors and have to clumsily ask what was even said, and/or feel embarrassed again for making other people even use Matrix. And I even use Labs and hydrated backup device enabled, I don't know what failed with that with us both not even switching devices - and I think that's less relevant than the question why it doesn't recover. These failures would be so much less disruptive and sad if the clients just talked this out.

Operating system

Fedora 36

Application version

Element version: 1.11.8 Olm version: 3.2.12

How did you install the app?

via flathub flatpak

Homeserver

matrix.org, room is also on matrix.org, other user also uses matrix.org. room has more than us two as users though, some of those from somewhere else

Will you send logs?

Yes

[uhoreg]

Just to confirm, was the other user using the same device when sending both the undecryptable messages and the succesfully-decrypted messages?

[ell1e]

If I understood their description right then yes. On my end no device switch either, it also was just minutes apart. Two messages mid conversation basically just failed out of the blue, it worked before and it worked after, but the two messages just never recovered.

[richvdh]

Hi, thanks for the report.

I've studied the logs and it looks like the original problem was due to #23792. In this case it looks to have been triggered by the sender using element in two tabs at once (not that that is an unreasonable thing to do!)

duplicate of #23792.