Follow-up to #938, which fixed the two reachable orderings but deliberately left this one open.
The residual window
createCollection() creates the physical table first and inserts the metadata row second, so between those two steps a collection exists that nothing in metadata describes. A second creator that reads metadata inside that window sees nothing, takes the adapter's Duplicate as proof of an orphan, and drops the first creator's table. The first creator's metadata insert then commits, pointing at a collection that is no longer there.
#938 re-reads metadata past the cache before concluding a table is an orphan, which removes the orderings that a rolling restart actually hit, and stops the loser from rolling back a table the winner owns. It does not make the sequence atomic — nothing serialises the two creators.
Proposed fix
Insert the metadata row first, then create the physical table. The unique key on _uid becomes the claim: exactly one creator wins it, and the loser gets Duplicate before it can touch any schema. On a physical-create failure the winner rolls back its own metadata row.
This is a design change, not a patch:
- it inverts the ordering of a hot path
- the transient orphan state becomes "metadata without a table" instead of "table without metadata", so orphan recovery has to be rewritten around the new shape
- every existing rollback path changes what it is rolling back
Testing
Needs a seam the code does not currently have: a way to pause one creator after its schema write and before its metadata write, so a second creator can be driven through the window deterministically. #938's testCreateCollectionConcurrentlyKeepsPeerData covers the cache-driven orderings but cannot reach this one.
The absence of that seam is itself part of the work.
Follow-up to #938, which fixed the two reachable orderings but deliberately left this one open.
The residual window
createCollection()creates the physical table first and inserts the metadata row second, so between those two steps a collection exists that nothing in metadata describes. A second creator that reads metadata inside that window sees nothing, takes the adapter'sDuplicateas proof of an orphan, and drops the first creator's table. The first creator's metadata insert then commits, pointing at a collection that is no longer there.#938 re-reads metadata past the cache before concluding a table is an orphan, which removes the orderings that a rolling restart actually hit, and stops the loser from rolling back a table the winner owns. It does not make the sequence atomic — nothing serialises the two creators.
Proposed fix
Insert the metadata row first, then create the physical table. The unique key on
_uidbecomes the claim: exactly one creator wins it, and the loser getsDuplicatebefore it can touch any schema. On a physical-create failure the winner rolls back its own metadata row.This is a design change, not a patch:
Testing
Needs a seam the code does not currently have: a way to pause one creator after its schema write and before its metadata write, so a second creator can be driven through the window deterministically. #938's
testCreateCollectionConcurrentlyKeepsPeerDatacovers the cache-driven orderings but cannot reach this one.The absence of that seam is itself part of the work.