[Story] Message queue and interactions

[manuroe]

As a user, I want to see the sending status in the timeline when posting a message:

• if I leave the room screen and come back, the pending or failed messages must be displayed
• I must be able to retry a failed sending or cancel it
• I must be able to cancel a sending in progress

• messages that failed to sent must be highly visible in the timeline

  Timestamp and postion in the timeline (doc):

• local echo timestamp and position must be the one when the users hit the send button
• timestamp and position must be updated when the message hit the server (come back from /sync)

### Tasks for BBQ Release
- [ ] https://github.com/matrix-org/matrix-rust-sdk/pull/2053
- [ ] Timestamp and position in the timeline (https://docs.google.com/document/d/1ADRIB2fF1iVrwkeZmrPQHBzI5jb7NuPxn8_e5wDKw7M/edit#heading=h.csfcjurtyab9)
- [x] I must be able to retry a failed sending or cancel it
- [x] Messages that failed to sent must be highly visible in the timeline
- [ ] if I switch the room and come back, the pending or failed messages must be still displayed in the timeline

### Tasks
- [ ] I must be able to cancel a sending in progress (Not for BBQ)

• [ ] QA signoff on completion
• [ ] Design signoff on completion
• [ ] Product signoff on completion

Stretch goals

None at this time

## Out of scope - Media upload - App restart

[jplatte]

I wonder what should happen when there is already one message (or more) in failed state, and the user sends another message. I think both of the following options are reasonable:

• Create a local echo that's immediately in failed / cancelled state
• Create a local echo in pending state and also update all failed / cancelled items to pending, retrying them in order

There could even be some failed and some pending local echoes at the same time (in the case multiple messages failed and just one was retried). Again the question arises what to do when a message is sent (i.e. a new local echo added).

[VolkerJunginger]

Once a message has failed completely and only can be send again manually by re-triggering the message should not be part of the queue anymore. The user would see the message (locally) in the timeline with the error message "Cannot be send".

Any following message should enter the queue and be send.

It's debatable how long the failed message should stay locally on the phone. WA for example keeps all failed messages forever (unless you uninstall the app)

[jplatte]

Okay. What I'm a little worried about then is the case of the previous message entering failed state just as the user is about to send another message. They probably don't intend the second one to be sent before / independently of the first (now failed) one, right? Anyways, can always revisit later.

[VolkerJunginger]

Yes, that's true but a scenario I could live with.

[manuroe]

Most if not everything was covered by https://github.com/element-hq/element-internal/issues/312