Laravel Events: SerializesModels Trait Causing getOriginal() Values to Show Same as Current Values

[AsmitNepali]

I'm experiencing inconsistent behavior with Laravel events when trying to access original model values for email notifications. I have two similar events, but one shows correct original vs. changed values while the other shows both values as the same.

Here's a simplified example with a User model that has a status field:

Observer

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->isDirty('status')) {
            UserStatusChangedEvent::dispatch($user);
        }
    }
}

The Problem

I have two similar events:

Event A (With SerializesModels):

class UserStatusChangedEvent implements ShouldBroadcastNow
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(public User $user) {}

    public function getTemplateData(): array
    {
        return [
            'user_name' => $this->user->name,
            'new_status' => $this->user->status->getLabel(),
            'old_status' => $this->user->getOriginal('status')?->getLabel() ?? 'unknown',
        ];
    }
}

Event B (Without SerializesModels):

class UserStatusChangedEventV2 implements ShouldBroadcastNow
{
    use Dispatchable, InteractsWithSockets; // No SerializesModels

    public function __construct(public User $user) {}

    public function getTemplateData(): array
    {
        return [
            'user_name' => $this->user->name,
            'new_status' => $this->user->status->getLabel(),
            'old_status' => $this->user->getOriginal('status')?->getLabel() ?? 'unknown',
        ];
    }
}

Test Case

// Update user status from 'active' to 'suspended'
$user = User::find(1);
$user->update(['status' => UserStatus::SUSPENDED]);

Results

Event A (With SerializesModels):

[
    'user_name' => 'John Doe',
    'new_status' => 'Suspended',
    'old_status' => 'Suspended'  // ❌ Wrong! Should be 'Active'
]

Event B (Without SerializesModels):

[
    'user_name' => 'John Doe',
    'new_status' => 'Suspended',
    'old_status' => 'Active'     // ✅ Correct!
]

Questions

1. Why does SerializesModels cause getOriginal() to return the current value instead of the original?
2. Is this the expected behavior when using SerializesModels with ShouldBroadcastNow?
3. What's the recommended approach for accessing original values in events that need serialization?
4. Are there any downsides to removing SerializesModels from events that implement ShouldBroadcastNow?

[fireflysub]

This is expected behavior. When you use a Serialize model, it only stores the model's identifier and class name. When the job is processed later, it retrieves the fresh model data from the database using that identifier.
Key Benefits:
Prevents Stale Data: By re-fetching the model from the database, you always get the current state of the model, not the state it was in when the job was queued.
Memory Efficiency: Only stores the model ID rather than the entire model data, reducing the payload size.
Handles Relationships: Automatically serializes and unserializes model relationships in the same way.

[AsmitNepali]

@fireflysub Thanks for the reply!

[macropay-solutions]

@AsmitNepali
You can bypass this behaviour by passing to the job the getOriginal array and also the $model->attributesToArray() as a json.

class UserObserver
{
public function updated(User $user): void
{
if ($user->isDirty('status')) {
UserStatusChangedEvent::dispatch($user);
}
}
}

Note:
on updating use isDirty getDirty
on updated use wasChanged getChanges

use getOriginal on both

[AsmitNepali]

@macropay-solutions thanks for the reply,
You mean something like this?

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->isDirty('status')) {
            UserStatusChangedEvent::dispatch(
                $user,
                $user->getOriginal(),
                $user->getChanges());
        }
    }
}

[macropay-solutions]

@AsmitNepali

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->wasChanged('status')) {
            UserStatusChangedEvent::dispatch(
                $user->getOriginal(),
                $user->getChanges());
        }
    }
}

or

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->wasChanged('status')) {
            UserStatusChangedEvent::dispatch((object)[
                'o' => $user->getOriginal(),
                'c' => $user->getChanges()
            ]);
        }
    }
}

or

or

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->wasChanged('status')) {
            UserStatusChangedEvent::dispatch((object)[
                'o' => $user->getOriginal(),
                'a' => $user->attributesToArray()
            ]);
        }
    }
}

//And you fetch the used from db only if needed using $object->a['id']

[crynobone]

With latest Laravel you can get the previous and changes directly from the model.

class UserObserver
{
    public function updated(User $user): void
    {
        if ($user->isDirty('status')) {
            UserStatusChangedEvent::dispatch($user, $user->getPrevious(), $user->getChanges());
        }
    }
}

[crynobone]

it follows the same structure as changes. only provides previous value from what's has been changed.

[macropay-solutions]

#53901

This change make it possible to retrieve the previously saved state (i.e. what original was before update/save). This gives you the ability to do similar checks as with current vs original state after save.
This adds ->getPrevious($key = null, $default = null) and ->getRawPrevious($key = null, $default = null), as well as syncPrevious() but it might be better to make the latter protected.
I also noticed a delete test in the EloquentUpdateTest so I moved it to the EloquentDeleteTest and added a correct test case in EloquentUpdateTest in its place.

#55729

Based on #53901 but instead of mimicking $original, $previous instead follows $changes.

Timelines:

• model retrieved from db - previous1 === original1 === current 1
• model modified event updated - previous1 , original1 , current 2
• model modified event saved - previous1 , original1 , current 2
• model modified after saved event - previous1 , original2 === current 2
  ? @crynobone

[crynobone]

yes

[macropay-solutions]

The in this case previous brings complications if the model is updated twice:

Timelines update 1:

• model retrieved from db - previous1 === original1 === current 1
• model modified event updated - previous1 , original1 , current 2
• model modified event saved - previous1 , original1 , current 2
• model modified after saved event - previous1 , original2 === current 2

Timelines update 2:

• model state - previous1, original2 === current 2
• model modified event updated - previous2 = original2, current 3
• model modified event saved - previous2 = original 2, current3
• model modified after saved event - previous2 , original3 === current3

and according to your last changes previous from the above follows $changes not $original. so:

Timelines update 2:

• model state - previous1 (keeps old values that were changed), original2 === current2
• model modified event updated - previous2(old values that were changed) ~= original2, current3
• model modified event saved - previous2(keeps old values that were changed) ~= original2, current3
• model modified after saved event - previous2(keeps old values that were changed) , original3 === current3

Conclusion if that previous should only be used for >=2 updates logic not for 1 update logic.

[crynobone]

Yeah, and so does changes, that's why I said it follows the same structure as changes. only provides previous value from what's has been changed.