You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For regular events and dependent events, the send queue can abort sending. If the underlying event was not being sent at the time of the abort request, then it's removed from the send queue's storage; otherwise, it results in a redaction event being sent to the server.
However, this is not infallible if a user tries to do it the other way, i.e. there was a reaction to an event, and they try to redact it and add it again. In this case, since the redaction isn't handled by the send queue, it may happen before or after the reaction has been added back, resulting in weird errors and situations (i.e. after removing and re-adding the reaction, it's not clear what's the final state of the reaction is in the room — and the timeline may show something that's temporarily incorrect, as a result).
Reusing the send queue for redactions would generally solve the problem of ordering here, and make it possible to ensure a total ordering for sending and redacting events in general. It could also mean that we may have local echo for redactions; this would require remembering what the redacted event was, for a short period of time, in case the redaction itself fails, but that's not intractable.
The text was updated successfully, but these errors were encountered:
For regular events and dependent events, the send queue can abort sending. If the underlying event was not being sent at the time of the abort request, then it's removed from the send queue's storage; otherwise, it results in a redaction event being sent to the server.
However, this is not infallible if a user tries to do it the other way, i.e. there was a reaction to an event, and they try to redact it and add it again. In this case, since the redaction isn't handled by the send queue, it may happen before or after the reaction has been added back, resulting in weird errors and situations (i.e. after removing and re-adding the reaction, it's not clear what's the final state of the reaction is in the room — and the timeline may show something that's temporarily incorrect, as a result).
Reusing the send queue for redactions would generally solve the problem of ordering here, and make it possible to ensure a total ordering for sending and redacting events in general. It could also mean that we may have local echo for redactions; this would require remembering what the redacted event was, for a short period of time, in case the redaction itself fails, but that's not intractable.
The text was updated successfully, but these errors were encountered: