A persist() in the gap between a write's finally and its queued write's start can run alongside that queued write #3063

Overview

runOperation's finally block in SimplePersistenceCoordinator registers a placeholder for the next queued write, then clears executingOperations, then starts the queued write in a microtask. If a persist() for the same node runs inside that gap (for example, code awaiting the finished write's promise), it sees the node as not executing:

• cancelPending() deletes the queued write's placeholder.
• The new write starts while the queued write also starts, so two writes for one node are in flight at once. That can cause an OCC version conflict.
• The queued write's own finally can then delete the newer write's entry.

Direction

• Keep the node marked as executing until the queued write has actually started. For example, hand the executing marker straight to the queued write in finally instead of clearing it and re-setting it a microtask later.

Acceptance Criteria

• A persist() that runs between a write finishing and its queued write starting queues behind the queued write
• Only one write per node is ever in flight
• A regression test covers the gap

Related

• Found during review of PR Flush waits on the node's current pending write and never deletes an entry it did not start (closes #3059) #3061. The race already existed; that PR did not introduce it.