Delete one player and everything core holds about them, in one transaction.

This is the single place core deletes a player. asobi_guest_reaper is one caller of it, not the site itself, and the operator-facing route (POST /api/v1/ops/players/:id/erase) is another.

Why the child list is written out here

All 15 core foreign keys into players.id are ON DELETE NO ACTION, so the player row cannot go until every child has. A blanket ON DELETE CASCADE migration would be shorter and is deliberately refused: a database cascade fires below this function's control flow, so asobi_extension_erase would never run, and iap_transactions - real-money receipts - would be destroyed silently. Enumerating the children in code is what makes the policy readable, testable and auditable. It is also exactly what guides/extensions.md tells extension authors to do, so core doing otherwise would be telling them one thing and doing another.

Delete, or sever

Two core tables are severed rather than deleted, and only two:

• iap_transactions - a purchase record outlives the account. A refund or chargeback dispute needs the provider transaction id, and statutory retention beats erasure for it. asobi_transaction is not this table: it is soft-currency bookkeeping keyed on wallets, and it goes with the wallet.
• groups.creator_id - deleting the group to free the key would destroy every other member's data.

Everything else is deleted outright. That is the anonymisation: every player-referencing table stores a bare uuid and nothing else about the person, so once players and player_identities are gone the surviving ids resolve to nobody. A tombstone player row would be a record about a person who asked to be erased, and it would still need a unique username.

Three columns hold ids with no foreign key at all, and each is left alone on that argument rather than by oversight:

• match_records.players - a jsonb list of ids.
• votes.votes_cast - a jsonb object keyed by voter id, #{VoterId => OptionId}. Same shape of argument, and it is exported (see asobi_player_export), so it is named here too.
• zone_snapshots.entities - opaque game-defined state. A game may key entities by player id, so this one is not core's to reason about; a game that puts personal data in it owns erasing it, which is what asobi_extension:erase_player/1 is for.

Atomic, never best-effort

One transaction, every result asserted, so a bare {error, _} becomes a badmatch that raises and rolls the whole thing back. A half-finished erasure that reports success is a worse answer to a deletion request than one that fails loudly and can be retried - the argument asobi_extension:erase_player/1 already makes for extensions, applied to core's own tables.

The audit row commits with the erasure

ADR 0007's rule is that the audit runs after the mutation and never fails it. Erasure is the stated exception: the data is gone by definition, so the audit row is the only surviving evidence the request was honoured. It is written inside the transaction through asobi_ops_audit:record_strict/4, and a failed insert rolls the erasure back. ops_audit_entries carries no foreign key to players, so the row outlives its own target by construction.

An automated retention sweep writes no rows - see asobi_guest_reaper.

What the transaction cannot cover

Evicting the player from asobi_auth_cache and from every live asobi_leaderboard_server, and killing the live session, run after the commit, because an ETS eviction and a process exit cannot roll back. All are idempotent, so a retry is safe. See after_commit/1.