Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
send queue: use
being_sent
as a lock for touching storage
There were two disconnected sources of truth for the state of event to be sent: - it can or cannot be in the in-memory `being_sent` map - it can or cannot be in the database Unfortunately, this led to subtle race conditions when it comes to editing/aborting. The following sequence of operations was possible: - try to send an event: a local echo is added to storage, but it's not marked as being sent yet - the task wakes up, finds the local echo in the storage,... - try to edit/abort the event: the event is not marked as being sent yet, so we think we can edit/abort it - ... having found the local echo, it is marked as being sent. This would result in the event misleadlingly not being aborted/edited, while it should have been. Now, there's already a lock on the `being_sent` map, so we can hold onto it while we're touching storage, making sure that there aren't two callers trying to manipulate storage *and* `being_sent` at the same time. This is pretty tricky to test properly, since this requires super precise timing control over the state store, so there's no test for this. I can confirm this avoids some weirdness I observed with `multiverse` though.
- Loading branch information