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
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.
0 commit comments