In Laravel, why can a job dispatched inside DB::transaction during sign-up fail on the worker, and how does afterCommit fix it?

## The race Sign-up usually writes several rows at once — the user, a team, a default settings row — so it runs inside `DB::transaction()`. Sending the welcome email is slow, so it is queued. The natural code dispatches `SendWelcomeEmail` inside the transaction closure, right after `User::create()`. The job, however, is handed to the queue backend as soon as the `PendingDispatch` is destroyed, which is before the closure returns and the transaction commits. A worker polling Redis or SQS can pop it within milliseconds. What happens next: 1. The worker unserializes the job, and `SerializesModels` re-queries the user by key on the worker's own connection. 2. Under normal isolation, that connection cannot see a row that another connection has inserted but not committed. 3. `firstOrFail()` throws `ModelNotFoundException`, and the queue handler marks the job **failed** at once. 4. If instead the job runs after an update inside the transaction, it sees the old values. 5. If the transaction rolls back after the job ran, the email went to a user who was never created. The bug is timing-dependent, so it appears under load or after a queue backend change, not on a developer machine. ## The fixes **Per dispatch** — chain `afterCommit()`: - `SendWelcomeEmail::dispatch($user)->afterCommit();` **Per connection** — set the option on the connection in `config/queue.php`: - `'after_commit' => true` makes every job on that connection wait for commits; the Laravel 13 skeleton ships `false` on each connection. - `->beforeCommit()` opts one dispatch out again. **Per class** — implement `Illuminate\Contracts\Queue\ShouldQueueAfterCommit`, which extends `ShouldQueue`. With any of these, the queue checks whether a transaction manager is bound and, if so, registers the push as a callback on the current transaction instead of pushing now. ## Exactly what afterCommit does | Situation at dispatch | Result | |---|---| | No transaction open | pushed immediately | | Inside a transaction, later committed | pushed after the **outermost** transaction commits | | Inside nested transactions | waits for the outermost commit, not the inner savepoint | | Transaction rolled back | the job is discarded, never pushed | | Job also implements `ShouldBeUnique` | its unique lock is released on rollback | The docs note that the connection-level `after_commit` also applies to queued event listeners, mailables, notifications and broadcast events sent on that connection. ## Why it often appears after switching to Redis The skeleton's `database` queue connection sets `'connection' => env('DB_QUEUE_CONNECTION')`, which is empty by default, so jobs are inserted through the **application's own** database connection. Inside a transaction, the `INSERT` into the `jobs` table is part of that transaction: the worker cannot see the job row until it commits, and a rollback removes it. That largely hides the race. Move the queue to Redis, SQS or a separate queue database and the push is no longer transactional, so the race appears. Relying on that side effect is fragile; declare the intent with `afterCommit`. ## Confirming the diagnosis The race leaves a recognisable trail: - the `failed_jobs` table holds `SendWelcomeEmail` entries whose exception reads `No query results for model [App\Models\User]` followed by the new user's id; - retrying those failed jobs later succeeds, because the row now exists; - the failures cluster around traffic peaks or right after the queue backend changed; - the failures disappear when the queue is backed up, because by the time a worker reaches the job the transaction has committed. A quick confirmation in a local environment is to add a short `sleep()` after the dispatch inside the transaction and run a worker on Redis: the job fails every time. Remove the sleep, add `afterCommit()`, and it succeeds every time. ## Related but different tools - `DB::afterCommit()` runs an arbitrary callback after commit; it belongs to the database layer, not the queue API. - `dispatchAfterResponse()` delays until after the HTTP response, not the commit, and has no retries. - Making the job tolerate a missing model (`#[DeleteWhenMissingModels]`) hides the symptom but still loses the email. `afterCommit` removes one duplicate-looking failure mode, but it does not make delivery exactly-once: a job can still run twice after a worker crash, so the email job itself should tolerate a retry.