getChanges() incorrectly reports stale data after refresh or repeated updates, causing unnecessary events like Scout's MakeSearchable

[hadi60]

Laravel Version

12.19.3

PHP Version

8.2-fpm

Database Driver & Version

mariadb:10

Description

In Laravel 12, calling $model->getChanges() after performing an update() and a subsequent refresh() incorrectly shows old changes instead of resetting to an empty array. This results in false positives when determining if a model has dirty attributes. It affects workflows where you conditionally trigger actions like Laravel Scout's MakeSearchable job based on whether actual changes occurred.

Steps To Reproduce

Product::factory();

// 1. Change a field
$product->update(['update_time' => now()]);
dump($product->getChanges());  // Expected: ["update_time" => "..."]

// 2. Update with the same value (no actual change)
$product->update(['active' => $product->active]);
dump($product->getChanges());  // Expected: [], but returns previous changes instead

// 3. Refresh the model
$product->refresh();
dump($product->getChanges());  // Expected: [], but sometimes still returns previous changes

// 4. Update another field
$product->update(['title' => '123']);
dump($product->getChanges());  // Expected: ["title" => "123"]

Expected Behavior:

• After an update, the $model->getChanges() should reflect only the actual changed attributes.
• After a refresh(), the change tracking should reset to an empty state.
• Updating with the same attribute value should not mark the model as changed.

Actual Behavior:

• getChanges() retains previous change state even after refresh().
• Updating with the same value still fires update events and jobs like MakeSearchable, even though no data changed.
• This causes unintended job dispatching and unnecessary syncing with search engines or other services.

Impact:

• Incorrect dirty state tracking causes performance issues when Scout, observers, or similar systems react to false changes.
• This breaks a common optimization pattern where developers rely on $model->getChanges() to detect real changes before syncing with external services.

[macropay-solutions]

After a refresh(), the change tracking should reset to an empty state.

Maybe fresh() is what you seek for this case.

Updating with the same attribute value should not mark the model as changed.

If you update with the same value $this->isDirty() will be false and the $this->syncChanges(); will not be called. Also updated event will not be fired.

    public function save(array $options = [])
    {
        $this->mergeAttributesFromCachedCasts();

        $query = $this->newModelQuery();

        // If the "saving" event returns false we'll bail out of the save and return
        // false, indicating that the save failed. This provides a chance for any
        // listeners to cancel save operations if validations fail or whatever.
        if ($this->fireModelEvent('saving') === false) {
            return false;
        }

        // If the model already exists in the database we can just update our record
        // that is already in this database using the current IDs in this "where"
        // clause to only update this model. Otherwise, we'll just insert them.
        if ($this->exists) {
            $saved = $this->isDirty() ?
                $this->performUpdate($query) : true;
        }

        // If the model is brand new, we'll insert it into our database and set the
        // ID attribute on the model to the value of the newly inserted row's ID
        // which is typically an auto-increment value managed by the database.
        else {
            $saved = $this->performInsert($query);

            if (! $this->getConnectionName() &&
                $connection = $query->getConnection()) {
                $this->setConnection($connection->getName());
            }
        }

        // If the model is successfully saved, we need to do a few more things once
        // that is done. We will call the "saved" method here to run any actions
        // we need to happen after a model gets successfully saved right here.
        if ($saved) {
            $this->finishSave($options);
        }

        return $saved;
    }

    protected function performUpdate(Builder $query)
    {
        // If the updating event returns false, we will cancel the update operation so
        // developers can hook Validation systems into their models and cancel this
        // operation if the model does not pass validation. Otherwise, we update.
        if ($this->fireModelEvent('updating') === false) {
            return false;
        }

        // First we need to create a fresh query instance and touch the creation and
        // update timestamp on the model which are maintained by us for developer
        // convenience. Then we will just continue saving the model instances.
        if ($this->usesTimestamps()) {
            $this->updateTimestamps();
        }

        // Once we have run the update operation, we will fire the "updated" event for
        // this model instance. This will allow developers to hook into these after
        // models are updated, giving them a chance to do any special processing.
        $dirty = $this->getDirtyForUpdate();

        if (count($dirty) > 0) {
            $this->setKeysForSaveQuery($query)->update($dirty);

            $this->syncChanges();

            $this->fireModelEvent('updated', false);
        }

        return true;

[crynobone]

getChanges() retains previous change state even after refresh().

Expected behavior, only refresh() run syncOriginal() with reset $changes

Updating with the same value still fires update events and jobs like MakeSearchable, even though no data changed.

Does it? Existing unit/integration tests doesn't indicate this. Please submit reproducing repository for us to debug.

[hadi60]

Job: App\Jobs\MakeSearchable 17s ago  
array:1 [▼
  "update_time" => "2025-07-10 12:02:11"
]
Job: App\Jobs\MakeSearchable 17s ago
array:1 [▼
  "update_time" => "2025-07-10 12:02:11"
]
Job: App\Jobs\MakeSearchable 17s ago
[]
Job: App\Jobs\MakeSearchable 17s ago
array:1 [▼
  "update_time" => "2025-07-10 12:02:11"
]
Job: App\Jobs\MakeSearchable 17s ago
array:1 [▼
  "update_time" => "2025-07-10 12:02:11"
]

    Route::get('/test', function () {
        $product = Product::find(50360);
        // 1. Change a field
        $product->update(['update_time' => now()]);
        dump($product->getChanges());  // Expected: ["update_time" => "..."]

        // 2. Update with the same value (no actual change)
        $product->update(['active' => $product->active]);
        dump($product->getChanges());  // Expected: [], but returns previous changes instead

        dump($product->getDirty());

        // 3. fresh the model
        $product->fresh();
        dump($product->getChanges());  // Expected: [], but sometimes still returns previous changes

        // 4. Update another field
        $product->update(['title' => '123']);
        dump($product->getChanges());  // Expected: ["title" => "123"]
    });

1- Job fired 3 time (Telescope says)
2- you are right, count($this->getDirtyForUpdate()) is zero but MakeSearchable is fired !

[macropay-solutions]

Maybe Laravel Scout is the place to fix this.

[hadi60]

getChanges() retains previous change state even after refresh().

Expected behavior, only refresh() run syncOriginal() with reset $changes

Updating with the same value still fires update events and jobs like MakeSearchable, even though no data changed.

Does it? Existing unit/integration tests doesn't indicate this. Please submit reproducing repository for us to debug.

https://github.com/Jooyeshgar/scout-test

sail up -d
sail artisan key:generat
sail artisan migrate
sail artisan test 

[hadi60]

    echo "=== 2. Update with the same value (no actual change) ===\n";
    $currentIsActive = $product->is_active;
    echo "Current is_active value: " . ($currentIsActive ? 'true' : 'false') . "\n";
    $product->update(['is_active' => $currentIsActive]);
    echo "getChanges(): ";
    var_dump($product->getChanges());
    echo "Expected: [] (empty array)\n";
    echo "getDirty(): ";
    var_dump($product->getDirty());
    echo "Expected: [] (empty array)\n\n";

=== 2. Update with the same value (no actual change) ===
Current is_active value: true
"toSearchableArray" // app/Models/Product.php:38

getChanges(): array(1) {
  ["price"]=>
  int(123)
}
Expected: [] (empty array)
getDirty(): array(0) {
}
Expected: [] (empty array)

For the above code, the 'updating' event is not called, but 'toSearchableArray' is called.
getChanges() shows the previous changes, and getDirty() is empty.

Is this correct?

1 - If nothing was updated, why is toSearchableArray called?
2 - Why is getDirty() not equal to getChanges()?

[macropay-solutions]

2 - Why is getDirty() not equal to getChanges()?

getDirty is for before update (updating). getChanges is for after update (updated). At least that is how we use them.

[macropay-solutions]

Maybe Laravel Scout is the place to fix this.

1 - If nothing was updated, why is toSearchableArray called?

@hadi60
https://github.com/laravel/scout/blob/c80f4c6bc05742398fc356caec1569a6e73f3771/src/ModelObserver.php#L91
saved event is used by Scout.

        if ($this->exists) {
            $saved = $this->isDirty() ?
                $this->performUpdate($query) : true;
        }

Saved is true so the event is fired.

        if ($saved) {
            $this->finishSave($options);
        }

Which basically in this case just syncs the original with the same thing, so does nothing.

    protected function finishSave(array $options)
    {
        $this->fireModelEvent('saved', false);

        if ($this->isDirty() && ($options['touch'] ?? true)) {
            $this->touchOwners();
        }

        $this->syncOriginal();
    }

Scout should listen for created and updated rather than saved as events.

Side note. Setting up your search engine (elastic search for example) to ingest in a loop last 2 minutes of updated/created rows is more efficient than the event driven ingestion.

[hadi60]

Scout listens to the saved event, and I think that’s correct.
If neither created nor updated is called, then the saved event shouldn't be triggered either.
Also, getChanges must have the correct value to decide whether toSearchableArray should be called.
Am I wrong?

[macropay-solutions]

@hadi60 changing the event logic is a breaking change. You are right in your reasoning...

You can overwrite this function in your model:

    public function save(array $options = [])
    {
        $this->mergeAttributesFromCachedCasts();

        $query = $this->newModelQuery();

        // If the "saving" event returns false we'll bail out of the save and return
        // false, indicating that the save failed. This provides a chance for any
        // listeners to cancel save operations if validations fail or whatever.
        if ($this->fireModelEvent('saving') === false) {
            return false;
        }

        // If the model already exists in the database we can just update our record
        // that is already in this database using the current IDs in this "where"
        // clause to only update this model. Otherwise, we'll just insert them.
        if ($this->exists) {
            $saved = $this->isDirty() ?
                $this->performUpdate($query) : null; // ...............................................see here
        }

        // If the model is brand new, we'll insert it into our database and set the
        // ID attribute on the model to the value of the newly inserted row's ID
        // which is typically an auto-increment value managed by the database.
        else {
            $saved = $this->performInsert($query);

            if (! $this->getConnectionName() &&
                $connection = $query->getConnection()) {
                $this->setConnection($connection->getName());
            }
        }

        // If the model is successfully saved, we need to do a few more things once
        // that is done. We will call the "saved" method here to run any actions
        // we need to happen after a model gets successfully saved right here.
        if (true === $saved) { // ...................................................................see here
            $this->finishSave($options);
        }

        return $saved ?? true; // ....................................................................see here
    }

[crynobone]

Also, getChanges must have the correct value to decide whether toSearchableArray should be called.

toSearchableArray may contains values from relationship and not just the current model, and I believe that's the reasoning for different behaviour between Eloquent and Scout.