Writing safely
A status change touches the claim and the audit log, and sometimes another account's claim too. It has to happen completely or not at all.
The one way a status changes
In claim-service.ts the service reaches this through one small helper, move. It calls applyTransition, and if that succeeded it calls alerts.statusChanged with the status before and the claim after. The alert is asked for only after the transaction has committed, so a failed email can never roll a status change back. The Alerts chapter picks up from there.
Taking a name from another account
When a claim passes a check and someone else owns the name, this runs instead.
Why a check is three separate writes
A check takes up to 8 seconds of network time. A transaction holds a database connection and possibly locks the whole while, so a check is split around the slow part.
If the process dies
Every way of crashing has been thought about, and none needs a person to clean it up.
| It dies | What recovers it | Result |
|---|---|---|
| Mid-transaction | Postgres rolls it back | Nothing happened |
| After startCheck, before finishCheck | The next startCheck closes any check older than 60 seconds | The claim isn't blocked |
| While a worker holds a lease | The lease expires after 60 seconds | Another worker picks it up |