News

Dispatch Events after a DB Transaction in Laravel 10.30

Published
Dispatch Events after a DB Transaction in Laravel 10.30 image

Release updates

Never miss a Laravel release

Get an email whenever a new Laravel release lands.

This week, the Laravel team released v10.30, which includes the ability to dispatch events based on a database transaction result. This week's release saw a lot of minor fixes, added tests, and miscellaneous changes. See the changelog for a complete list of updates.

Dispatch events based on a DB transaction result

Mateus Guimarães and Taylor Otwell collaborated on dispatching an event based on the result of an in-progress database transaction:

What this PR aims to do is to make the event itself aware of transactions. So, if a transaction fails, the event doesn't even get published. That way, it doesn't matter if the listeners are queued or not or if they have afterCommit enabled, and you can ensure, in the tests, that the event did not get published.

Thanks to this contribution, you can now add the ShouldDispatchAfterCommit interface to an event, which instructs the event dispatcher to hold off on dispatching the event until the transaction is committed; if the transaction is rolled back, the event does not fire.

Here's a contrived example of how it might work—given the following transaction and dispatch amid the transaction:

DB::beginTransaction();
 
Log::info("Transaction started");
$order = Order::create(['amount' => 5000]);
 
// More stuff...
 
Log::info("Dispatching OrderCreated event");
OrderCreated::dispatch($order);
 
Log::info("Closing transaction");
DB::commit();

Here's what the logs might look like:

local.INFO: Transaction started
local.INFO: Dispatching OrderCreated event
local.INFO: Closing transaction
local.INFO: Order created event handled...

And finally, the event might look like the following:

use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;
 
class OrderCreated implements ShouldDispatchAfterCommit
{
// ...
}

Along with ShouldDispatchAfterCommit, the pull request expanded to include other interfaces like ShouldHandleEventsAfterCommit for listeners and ShouldQueueAfterCommit, which may be implemented on jobs, listeners, mail, and notifications.

Test Improvements

Mior Muhammad Zaki contributed test improvements, getting Laravel compatible with the future release of PHPUnit 11—see Pull Request #48815 for details.

Release notes

You can see the complete list of new features and updates below and the diff between 10.29.0 and 10.30.1 on GitHub. The following release notes are directly from the changelog:

v10.30.1

v10.30.0

Paul Redmond photo

Staff writer at Laravel News. Full stack web developer and author.

Sponsored

acquaintsoft logo
Acquaint Softtech

Hire Laravel developers with AI expertise at $20/hr. Get started in 48 hours.

Visit Acquaint Softtech

The latest

View all →
Laravel 14 Adds a defaults() Method to Eloquent Models image

Laravel 14 Adds a defaults() Method to Eloquent Models

Read article
Laravel AI SDK and Laravel MCP Security Fixes: Update Now image

Laravel AI SDK and Laravel MCP Security Fixes: Update Now

Read article
Mailbox for Laravel: Preview and Test Rendered Email image

Mailbox for Laravel: Preview and Test Rendered Email

Read article
Count Worker Crashes as Job Exceptions in Laravel 13.34 image

Count Worker Crashes as Job Exceptions in Laravel 13.34

Read article
Elastic Bridge: Eloquent-Style Queries for Elasticsearch and OpenSearch image

Elastic Bridge: Eloquent-Style Queries for Elasticsearch and OpenSearch

Read article
Laravel Release Cycle: Versions, Support Policy, and Dates image

Laravel Release Cycle: Versions, Support Policy, and Dates

Read article