In Laravel, what does DB::transaction($callback, attempts: 5) actually retry, and what can go wrong when the loyalty-transfer closure runs a second time?

## What the `attempts` argument controls `DB::transaction(Closure $callback, int $attempts = 1)` runs its body in a `for` loop from attempt 1 to `$attempts`. Each pass calls `beginTransaction()`, runs the closure, and commits. With the default of `1` there is no retry at all; the docs describe the second argument as the number of times the transaction is retried when a **deadlock** occurs. ## Which failures loop again When the closure throws, Laravel rolls back and then consults a **concurrency error detector**. The default `ConcurrencyErrorDetector` returns true when: - the exception is a `PDOException` whose code is `40001` (serialization failure), or - the message contains one of a fixed list of phrases, including "Deadlock found when trying to get lock" (MySQL), "deadlock detected" (PostgreSQL), "Lock wait timeout exceeded; try restarting transaction", "database is locked" (SQLite) and "has been chosen as the deadlock victim" (SQL Server). Only when the detector says yes **and** attempts remain does the loop continue. Every other exception is rethrown after the first rollback: | Failure inside the closure | Retried with `attempts: 5`? | |---|---| | Deadlock or serialization failure | yes, up to 5 passes | | Lock wait timeout | yes | | Unique constraint violation | no | | Your own `InsufficientPoints` exception | no | | Lost connection mid-closure | no | A concurrency error raised by the `COMMIT` itself is handled the same way: the loop rolls back if needed and tries again while attempts remain. The detector is bound through a contract, so an app can register its own implementation to recognise additional errors. ## Nested transactions never retry If the closure runs inside an outer transaction, the database has already rolled back the **whole** transaction on a deadlock, so retrying only the inner part would be meaningless. Laravel therefore decrements the level and throws `Illuminate\Database\DeadlockException` from the inner call. The exception keeps the original message, so the **outermost** `transaction()` recognises it as a concurrency error and retries the entire unit if it was given attempts. Put `attempts:` on the outermost call; on an inner call it has no effect for deadlocks. ## What a second pass repeats The retry re-executes the closure from the top. That is correct for database work, which was rolled back, but wrong for anything else: 1. **External side effects repeat.** A notification sent, a payment captured or a message published inside the closure happens once per attempt. Defer them with `DB::afterCommit()` or do them after `transaction()` returns. 2. **In-memory state is stale or doubled.** Values read before the closure, counters incremented in PHP, or objects mutated by the first pass carry over. Re-read what you depend on inside the closure. 3. **Exceptions change shape.** After the last attempt the original exception is rethrown, so callers still need to handle a deadlock that retries could not resolve. ## A retry-safe loyalty transfer ```php use Illuminate\Support\Facades\DB; $transferId = DB::transaction(function () use ($from, $to, $points) { $ids = [$from, $to]; sort($ids); DB::table('members')->whereIn('id', $ids)->orderBy('id')->lockForUpdate()->get(); // debit, credit and ledger insert, reading fresh values here return DB::table('point_transfers')->insertGetId([/* ... */]); }, attempts: 3); // side effects only after a successful commit $notifier->pointsReceived($to, $points); ``` Locking both member rows in id order reduces how often two opposite transfers deadlock. The retry covers the deadlocks that still happen, and the notification is sent exactly once, after the loop has succeeded. ## What to say in an interview The strong answer names the default of one attempt, the concurrency-only filter, the nested-transaction exception, and the rule that everything inside the closure must be safe to run twice. Retrying a closure with side effects inside is the defect interviewers are fishing for.