local reactions followup: redacting then adding reaction fails in subtle ways

[bnjbvr]

• Report
• Rageshake

STR

• add a reaction to a timeline item, while online, wait for sync to stabilize the state
• get offline
• redact the reaction
• add the same reaction back

Analysis

What's happening, roughly:

• redacting the reaction removes the local echo
• the redaction request is sent in the background (by the timeline)
  • Suspicious thing 1: for some reason, the redaction fails, but is immediately retried without bumping the retry number
• adding the reaction again adds the local echo
• the send queue tries to send the reaction
• then getting back online
  • the send queue request is run first, the server fails and complains that the reaction already exists on this item
  • Bug 2: the redaction eventually happens, removing the reaction

So there are multiple solutions to this:

Have the send queue take care of redactions too

This would guarantee ordering of the requests, and would make sure that redaction happening offline get properly honored. It's not the first time I've told myself it'd be nice that the send queue handle redactions too, so maybe this is the way to go.

Add another ordering mechanism for reactions

Previous code before the huge refactoring of reactions would keep a list of actions to be performed, and update according to those. It's probably overkill, though.

Get rid of the optimistic rendering of redactions

And keep the timeline state lock while redacting. It might make it look like the timeline is completely wedged, though, esp. because of the suspicious thing in the above list.

Remove the retry mechanism for the redaction

I don't know which mechanism makes it retry like that endlessly, so this would require a bit of investigation.