Bug: two concurrent ALTER TABLE ADDs on one table both commit, and one column is lost #1471

Ladybug version

main at ec1b209 (built with #1468 applied, which only changes stats_info)

What operating system are you using?

macOS (arm64)

What happened?

With multi-writes enabled, two transactions can each add a column to the same node table, and both commit. Afterwards the table only has the column from the transaction that committed first. The other column is gone, and rows written by the transaction that added it show its values under the surviving column.

Creating a catalog entry checks for a write-write conflict (CatalogSet::createEntryNoLock calls checkWWConflict), but altering one doesn't: CatalogSet::alterEntry builds the new version from the entry the transaction sees and emplaces it with no conflict check. I think that's the cause, but I've only read the code, not traced it. The values ending up under x would fit both new properties getting the same catalog column ID while storage appends two columns.

#1435 proposes turning multi-writes on by default, which would make this reachable without the debug setting.

Are there known steps to reproduce?

CALL debug_enable_multi_writes=true;
CREATE NODE TABLE T(id INT64 PRIMARY KEY, b INT64);
CREATE (:T {id: 1, b: 10});

-- connection 1
BEGIN TRANSACTION;
CREATE (:T {id: 2, b: 20});
-- connection 2
BEGIN TRANSACTION;
ALTER TABLE T ADD x INT64 DEFAULT 1;
-- connection 1
ALTER TABLE T ADD y INT64 DEFAULT 2;
-- connection 2
COMMIT;
-- connection 1
COMMIT;

CALL table_info('T') RETURN *;
MATCH (t:T) RETURN t.* ORDER BY t.id;

Both COMMITs succeed. table_info lists only id, b and x, and the MATCH returns 1|10|1 and 2|20|2: row 2's x is 2, the default of the lost y. The result is the same after a CHECKPOINT, and y is also lost when connection 1 has no pending insert.

Expected: connection 1's ALTER or COMMIT fails with a write-write conflict, the way creating a catalog entry does, or both columns survive with their own values.