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

laravelcloud logo
Laravel Cloud

Easily create and manage your servers and deploy your Laravel applications in seconds.

Visit Laravel Cloud

The latest

View all →
CPX: The Composer Package Executor for PHP image

CPX: The Composer Package Executor for PHP

Read article
Laravel AI SDK Adds Human-in-the-Loop Tool Approval image

Laravel AI SDK Adds Human-in-the-Loop Tool Approval

Read article
Pest 5 Released With Test Impact Analysis, Agent Verification, and Evals image

Pest 5 Released With Test Impact Analysis, Agent Verification, and Evals

Read article
Queue-SQL: Run Mass Deletes and Updates Across Parallel Queue Jobs image

Queue-SQL: Run Mass Deletes and Updates Across Parallel Queue Jobs

Read article
Blade Formatting in Laravel Pint image

Blade Formatting in Laravel Pint

Read article
Inertia DevTools Is Now on the Chrome Web Store image

Inertia DevTools Is Now on the Chrome Web Store

Read article