[GenericJam]

MOB-502. Mob.Diag.StoreTest "a loss onto tables an older mob still holds…" spawns a process that owns the store's tables, and its on_exit only sent the kill. ExUnit runs on_exit callbacks in reverse order, so the setup's tear_down/1 ran right after. The holder's death (which deletes its tables) could land between tear_down's :ets.whereis and :ets.delete, and the delete raised ArgumentError.

Fix: the on_exit uses the module's kill/1, which waits for the exit, as the other holder in this file already did.

Reproduced on master: 1 failure in 63 runs of the file, the exact error from the issue. After: 903 runs (3×300 with --repeat-until-failure) with 0 failures. A separate failure appeared once at :191 (an eventually with a 1000 ms deadline) while the host was at load average ~400; it is unrelated and not changed here.

[GenericJam]

Review: reviewer subagent (Codex usage-limited): SHIP. Its P3 finding is fixed in fa37d3f: in the heir-kill test, the owner re-points its tables at the restarted heir after the assertions, so teardown could hit :ets.setopts mid-flight (16 owner crashes logged in 8,000 runs). The test now waits for both tables to name the new heir. After the fix: 2,001 runs of that test with 0 failures and 0 owner-crash logs; 301 runs of the whole file with 0 failures.