DEV Community: Nikita Sirenko

After save isn't after commit: the event trap Magento 2 and Laravel share

Nikita Sirenko — Thu, 12 Nov 2026 14:00:00 +0000

Magento's catalog_product_save_after runs before the COMMIT. So does Laravel's saved(), as soon as the save sits inside DB::transaction(). Publish to a queue from either, and a fast consumer can read the old row.

What one save does in Magento

In Magento 2, $productRepository->save() isn't one UPDATE. It opens a transaction, 2 levels deep: a CatalogSearch plugin opens one, the EntityManager another. Then it fires catalog_product_save_before, writes the product and its attribute values, fires catalog_product_save_after, and only then commits. Stock data, URL rewrites and the quote refresh hang off catalog_product_save_after. To add behavior, you declare an observer in events.xml.

Laravel has the same shape without the XML: an Eloquent observer with saving() and saved(), attached to the model with #[ObservedBy].

Before the commit

Publish to RabbitMQ from catalog_product_save_after and 2 things can go wrong. A fast consumer reads the product before the transaction ends and gets the old row. Or something fails later in the save, the transaction rolls back, and the ERP has already heard about a product that was never saved.

Magento's answer is a separate event. After the commit, the resource model runs its commit callbacks. One of them is Magento\Framework\Model\AbstractModel::afterCommitCallback(), and it fires catalog_product_save_commit_after. AbstractResource::commit() runs those callbacks only when the transaction level is back to 0. If your save is part of a bigger transaction, the event waits for the outermost commit.

The core uses that event sparingly. Across all areas, the core has 5 observers on catalog_product_save_before, 5 on catalog_product_save_after, and 1 on catalog_product_save_commit_after: ImageResizeAfterProductSave, which resizes the new product images.

The heavier jobs register commit callbacks directly. Search reindex does it in Update on Save mode. Since 2.4.9 catalog price rules do the same: before that, ApplyRules reindexed the saved product in an afterSave plugin, inside the transaction. The code comment says why it moved: to avoid DDL transaction issues.

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <!-- not catalog_product_save_after: that one runs before the COMMIT -->
    <event name="catalog_product_save_commit_after">
        <observer name="acme_notify_erp" instance="Acme\Catalog\Observer\NotifyErp"/>
    </event>
</config>

class NotifyErp implements ObserverInterface
{
    public function __construct(private PublisherInterface $publisher) {}

    public function execute(Observer $observer): void
    {
        $sku = $observer->getEvent()->getProduct()->getSku();
        $this->publisher->publish('acme.product.saved', $sku);
    }
}

The topic itself is declared in communication.xml, queue_publisher.xml and queue_topology.xml. All 3 are in this gist.

Laravel: the same problem, one level up

In Laravel, Eloquent's save() doesn't open a transaction. Only saveOrFail() does. saved() fires right after the query, and without a transaction that row is already committed. The problem shows up when you wrap the work in DB::transaction(), the normal way to save a product together with its prices.

The fix is an interface. An observer that implements ShouldHandleEventsAfterCommit gets its saved() after the outermost commit. Illuminate\Database\DatabaseTransactionsManager holds the call until then. No open transaction? It runs right away. Rollback? It never runs.

Before Laravel 12.54 the interface defers every method of the observer, saving() included, so a change you make to the model in saving() inside a transaction isn't written. Since 12.54 only the "after" methods wait. Keep an after-commit observer to saved() and the difference doesn't touch you.

For a job on its own there's ->afterCommit(), or 'after_commit' => true on the connection in config/queue.php. Laravel ships it as false on all 4 connections that have the option: Database, Beanstalkd, Redis and SQS.

class ProductObserver implements ShouldHandleEventsAfterCommit
{
    public function saved(Product $product): void
    {
        NotifyErp::dispatch($product->sku);
    }
}

#[ObservedBy(ProductObserver::class)]
class Product extends Model
{
    public function prices(): HasMany
    {
        return $this->hasMany(Price::class);
    }
}

DB::transaction(function () use ($product, $prices) {
    $product->save();
    $product->prices()->createMany($prices);
});
// saved() is called here, after the COMMIT

What waiting costs

After the commit there's nothing left to roll back. If the publish fails there, the product is saved and the message is lost.

Magento and Laravel handle that failure differently. Magento catches an exception thrown in a commit callback and logs it as CRITICAL in exception.log, and save() returns as if nothing happened. Laravel throws it to the caller of DB::transaction(), after the row is committed.

When the queue is in the same database

Then there's nothing to wait for: the publish is part of the transaction. Magento's MySQL queue inserts into queue_message through the default connection. Laravel's database queue driver does the same when it uses the app's default connection. A rollback removes the message, and no consumer sees it before the commit. If a message must not be lost, that's the setup that gives you both or neither.

Switch to RabbitMQ, Redis or SQS and that guarantee is gone. Your observer doesn't change by a line.

The rule

If a listener talks to the outside world, a queue, an API or an email, wait for the commit, and decide what happens when the call fails after it. Magento gives you a separate event. Laravel gives you an interface.

Next: Magento plugins and Laravel decorators, and why around plugins are the ones to watch.

Have you ever had a consumer read a row that wasn't committed yet?

Part 2 of 15 of the Magento 2 vs Laravel series. Originally published on LinkedIn.

bin/magento and php artisan are one Symfony Console in two costumes

Nikita Sirenko — Wed, 11 Nov 2026 18:34:39 +0000

I've worked in Magento 2 full-time for 5.5 years, and in Laravel on and off since 2015. Put the two side by side and the names change, but the engineering doesn't. The console is the clearest example.

Same component underneath

In Magento 2, Magento\Framework\Console\Cli, the class behind bin/magento, extends Symfony's Console Application. In Laravel, so does Illuminate\Console\Application, the class behind php artisan. Every command in both frameworks extends Symfony's Command.

So arguments, options, input, output and return codes work the same way. Only registration differs. Magento collects commands from di.xml. Laravel picks up the classes in app/Console/Commands.

The trap they share

When bin/magento starts, it builds every command registered in CommandListInterface, with all of its constructor dependencies, even if all you asked for was cache:flush. On a fresh Magento 2.4.9 install that's 72 command objects per run. One heavy constructor slows down every bin/magento call, the cron run that fires every minute included.

The classic fix is a generated Proxy, wired in di.xml. The heavy service is created only when the command actually runs. The core does this itself in the image-resize command.

<type name="Magento\Framework\Console\CommandListInterface">
    <arguments>
        <argument name="commands" xsi:type="array">
            <item name="acme_export" xsi:type="object">Acme\Export\Console\ExportOrders</item>
        </argument>
    </arguments>
</type>
<!-- built on every bin/magento run: inject the heavy service lazily -->
<type name="Acme\Export\Console\ExportOrders">
    <arguments>
        <argument name="exporter" xsi:type="object">Acme\Export\Model\OrderExporter\Proxy</argument>
    </arguments>
</type>

class ExportOrders extends Command
{
    public function __construct(private OrderExporterInterface $exporter)
    {
        parent::__construct('acme:export-orders');
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $output->writeln($this->exporter->export() . ' orders exported');
        return Cli::RETURN_SUCCESS;
    }
}

With the exporter injected directly, bin/magento cache:status builds it on every run. With the Proxy it doesn't, and acme:export-orders still prints "3 orders exported".

Since 2.4.8 there's a cleaner way. Magento\Framework\Console\CommandLoader implements Symfony's lazy CommandLoaderInterface. Register the command there by name, and Magento builds it only when you call it. No Proxy needed.

<!-- 2.4.8+: registered by name, built only when called -->
<type name="Magento\Framework\Console\CommandLoader">
    <arguments>
        <argument name="commands" xsi:type="array">
            <item name="acme_export" xsi:type="array">
                <item name="name" xsi:type="string">acme:export-orders</item>
                <item name="class" xsi:type="string">Acme\Export\Console\ExportOrders</item>
            </item>
        </argument>
    </arguments>
</type>

Laravel has the same split. A command without the #[AsCommand] attribute is resolved from the container when Artisan starts. With the attribute, it's registered by name and built only when you call it. Or you ask for the service in handle(), and the container resolves it on run. The make:command stub has no constructor and injects into handle(), so Laravel's default already avoids the trap.

Since Laravel 13, make:command writes a #[Signature] attribute instead of a $signature property. That attribute alone doesn't make the command lazy. Artisan only checks for #[AsCommand], so the example has both.

#[Signature('acme:export-orders')]
#[AsCommand(name: 'acme:export-orders')]
class ExportOrders extends Command
{
    public function handle(OrderExporter $exporter): int
    {
        $this->info($exporter->export() . ' orders exported');
        return self::SUCCESS;
    }
}

The rule

Keep command constructors cheap, or make them lazy. It holds in both frameworks because it's the same component.

This is the first of 15 short comparisons between Magento 2 and Laravel, one idea at a time, with code. Next: why a save event can fire before the commit in both frameworks, and what that does to a queue.

Which command in your project has the heaviest constructor?

Part 1 of 15 of the Magento 2 vs Laravel series. Originally published on LinkedIn.