It seems that you're dealing with a situation where the model object being tracked within a transaction is modified, which affects the behavior of the callbacks assigned to that transaction. This can lead to issues, especially when working with models in the context of a transaction, particularly in conjunction with events like updated.

In short, when a transaction is registered, Laravel creates callbacks that will be executed after the transaction is committed. If the model is modified during the transaction and Laravel uses the same object for the registered callbacks, this can lead to a scenario where the callbacks operate on outdated or inconsistent data.

In PHP, objects are passed by reference, meaning that if you modify an object in one place, those changes will be reflected everywhere that object is used unless you specifically clone the object before making changes.

This is a big issue when building a logging mechanism for registering model changes, imagine this pretty common example:

Model to watch

class Orderextends Model{protected$fillable = ['state_id',// ...   ];}

Model to log changes

#[ObservedBy(OrderObserver::class)]class OrderStatesextends Model{protected$fillable = ['order_id','old_state_id','new_state_id',// ...   ];publicfunctionorder():BelongsTo    {return$this->belongsTo(Order::class,'order_id','id');    }}

Observer code

class OrderObserverimplements ShouldHandleEventsAfterCommit{publicfunctionupdated(Order$model)// tried also updating with no luck    {$new_state_id =$model->state_id;$previous_state_id =$model->getOriginal('state_id'));// here I would like to log the change in a OrderStates entry// but real previous state_id is lost when wrapping the change in a transaction...    }}

Example code

DB::beginTransaction;$order = Order::find(1);$order->update(['state_id' =>2]);// other relevant code...DB::commit();

Is there any other clean way to do this?

Solution

1. Put this behavior in documentation (if not done already). This seems to be an issue converted into a discussion. Sad...
2. Stop usingShouldHandleEventsAfterCommit and use queue with delay. In that job check if the model has the new state and if so use the old state (including timestamp) sent in the job to notify or log things@yurik94 . Do not use model id as job payload. Use model to array.

Thank you for this. We had thoughts of using thisShouldHandleEventsAfterCommit but we never used it. Lucky us.

I have the same issue. Are there any updates?

I believe I've found a working solution for this! Avoid using ShouldHandleEventsAfterCommit and instead wrap any observer actions within manual DB::afterCommit() callbacks.

Using your example, modify the provided Observer like the following;

<?phpnamespaceTests;useIlluminate\Support\Facades\DB;usePHPUnit\Framework\Assert;class Observer{publicfunctionupdated(Test$model)    {$original =$model->getOriginal('test');DB::afterCommit(function ()use ($model,$original) {            Assert::assertEquals('updated',$model->test);            Assert::assertEquals('original',$original);        });    }}

This maintains proper event firing order (saving --> updating --> SQL executed --> updated) for both transactions & non-transactions (these will be executed immediately) and retains original model values, all while ensuring that any external actions still only happen after the SQL is committed to the database.

I was building something similar to what@yurik94 had suggested, an outbox-style logging system that was triggered from both transactions and non-transactions within my codebase. Interestingly (or frustratingly depending on how you look at it), assuming your observer is firing from a transaction AND you're only making DB changes, since the observer is ran on the same PHP thread the transaction rollbackwill properly undo any db changes. This flow retains atomicity, however if the observer can also be fired from outside of a transaction and the changes fail to commit to your database you will introduce ghost actions that shouldn't have occurred, breaking the atomicity.

By not using ShouldHandleEventsAfterCommit and instead using manual DB::afterCommit we are able to have the best of both worlds, atomicity on the save and atomicity on the executed observer actions.

Here's a real world example;

Situation: When a user's address is updated I want to send an email to them indicating changes were made while including the original address in the email.

<?phpnamespaceApp\Observers;useApp\Models\User;useIlluminate\Support\Facades\DB;useIlluminate\Support\Facades\Mail;useApp\Mail\AddressChangedEmail;class Observer{publicfunctionupdated(User$user)    {if ($user->wasChanged('address')) {$originalAddress =$user->getOriginal('address');DB::afterCommit(function()use ($user,$originalAddress) {                Mail::to([$user->email])->send(newAddressChangedEmail($user,$originalAddress));            });        }    }}

This solved the problem for me!