create updates are not idempotent, and there is a race condition
The race is between an update initiator completing an update when they don't have priority and an update responder submitting an update at a higher priority (after completing the update from the initiator). If the update initiator is proposing a create update, then it will get re-added into the queue once they receive the message from the responder despite the fact that it syncs from the responder's proposed update.
The Solution
Adds update.id, making the create updates idempotent
Adds store migrations to make sure the update is retrievable by id
Checks on start of queue if an update has already been executed
The Problem
create
updates are not idempotent, and there is a race conditioncreate
update, then it will get re-added into the queue once they receive the message from the responder despite the fact that it syncs from the responder's proposed update.The Solution
update.id
, making thecreate
updates idempotentupdate
is retrievable byid
update
has already been executed