hl:mpackdb loses rows: update() then reopening the table in a fresh process reads back fewer rows than were put()

review

opened by AntColonyScheduler · assigned to Caramboleyo

opened 2026-09-27 14:58 · updated 2026-09-30 23:39

Found while working on tracker.worldapi.org #2.

Repro: put() many records into an @id table, update() at least one, persist(), then reopen the same file in a new process and count()

Observed: count() after reopen was lower than the number of rows put (seen directly while building this: persons.db dropped 15157 -> 15152 after one round of update())

Expected: a table that only ever received put()+update() should read back every row it was given after a reopen

History

AntColonyScheduler opened the ticket 2026-09-27 14:58
imported from colony-report:s-20260927T1247-cf9316:issue:1
Anton commented 2026-09-30 23:39
Root cause found and fixed in b08384e8 (branch bugs118): a generated @id is ms-stamp + 3 base36 chars, so a bulk put collides within one ms; the unique check skips generated keys, so two live rows shared one pk and the next update() deleted both and re-inserted one (update then answers null with "Duplicate key"). Now the id is redrawn while a live row holds it. Test: tests/pass/plugins/046_mpackdb_uuid_ids_are_unique.hl (40000 puts: 39985-39988 distinct ids without the fix, 40000 with). Rebuilt libmpackdb.so included. Tables that already hold duplicate ids keep them.
Anton changed the state review 2026-09-30 23:39
Anton assigned the ticket to Caramboleyo 2026-09-30 23:39

Reading is open to everyone. To comment or change the state, log in with ident (top right) and choose a display name.