Can we have infinite retrying back?

[TR-SLimey]

Is your feature request related to a problem? Please describe.

When I send a message, I sometimes forget about it and expect it to be sent, only to later realize that it hasn't. I would prefer if messages would almost always resend, subject to the below rules:

Describe the solution you'd like

• Non-message events like reactions, redactions or room settings changes get priority - they are usually quite light so can send without blocking the queue for long, and Element can safely assume that sending them in the wrong order won't impact the conversation because it'll hardly be noticeable; after all, the end goal of those events matters (like updated room name, or incremented reaction counter), not when they are sent.
• All other events, messages especially, have to be sent in the right order when the above-mentioned events are brought to the top of the queue. This is because order matters for these events.
• All non-message and non-call events are automatically re-sent (room settings events only resent if that specific room setting has not been changed since the event was sent - this would require taking a snapshot of the room setting when changing room settings though this should be easy enough) because, once again, their order does not matter, so regardless of any changes in conversation, they are always valid.
• All message events are only re-sent if no message events (non-message events should be ignored) have been received in the meantime. This can be accomplished by waiting for sync to complete whenever internet connection is re-gained before re-sending message events (which also looks better, because having messages go through while Element is "connecting" looks like a bug). This will ensure that out-of-place messages will not randomly appear in the chat when one of the users re-connects to the internet.
• If messages have arrived, so the messages in the queue are not auto-resent, the user should still have the option to re-send the message as it is currently done.

Describe alternatives you've considered

I suppose the retry count could be increased, but this does not adapt to what is happening in the chat as the above does, and might not suit everyone, whilst the above is likely to work in all situations.

Additional context

This solution would likely fix #1967, #1884, #729, #361, #1846 and probably a few more.

[bmarty]

Yes, it will be restored. It's done in this not merged yet PR: #1889

[TR-SLimey]

But will that PR simply revert to infinite retries for everything, or will there be some structure to it, somewhat like outlined above? I think the above is the optimal way of handling retries personally, since it adapts to the events being sent and what is happening in the chat.

[bmarty]

Infinite retrying has been back in #1889

[dkasak]

I'm also curious whether the currently implemented message resend semantics are something like @TR-SLimey outlined above? If not, this bug could remain open since the solution outlined above is a good one (but the title should be changed to reflect it's an enhancement).