Bug Report: updateOrCreate() applies global scopes when finding, but ignores them when updating

[Sairahcaz]

Laravel Version

11.43.2

PHP Version

8.2.28

Database Driver & Version

mysql Ver 8.0.36 for macos14 on arm64 (MySQL Community Server - GPL)

Description

The updateOrCreate() method behaves inconsistently with regard to global scopes in Laravel:

• When finding the model via firstOrNew(), global scopes are applied.
• When updating the existing model via $model->save(), the resulting UPDATE query does not include any global scope constraints.

This inconsistency is particularly problematic in multi-tenant applications where global scopes are used to enforce tenant isolation (e.g. team_id, organization_id).

Expected Behavior
The UPDATE query should respect global scopes, just like the SELECT query does.

Thanks again for all the amazing work on Laravel!

Steps To Reproduce

1. Define a global scope on team_id:

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;

class Flight extends Model
{
    protected static function booted(): void
    {
        static::addGlobalScope('team', function (Builder $builder) {
            if (auth()->check()) {
                $builder->where('team_id', auth()->user()->team_id);
            }
        });
    }
}

2. Call updateOrCreate() on an existing record:

Flight::updateOrCreate(
    ['id' => 123], // Existing record with team_id = 1
    ['status' => 'delayed']
);

3. Observe the SQL queries:

-- SELECT query (correctly scoped):
SELECT * FROM flights WHERE id = 123 AND team_id = 1 LIMIT 1;

-- UPDATE query (missing scope!):
UPDATE flights SET status = 'delayed' WHERE id = 123;
-- ⚠️ Missing team_id = 1 in the WHERE clause

[macropay-solutions]

There is one problem. Events.
The update with scopes would become mass update and events would not be triggered.

But in order for an update to happen, the row must be found in db via scopes from firstOrNew, no?
So, if the scopes are applied when retrieving the row from db then why is that an issue?

Or the issue is on create rather than update?

[macropay-solutions]

Are you using composed primary keys or composed unique constraints instead of primary id?

If yes then you can define your model to use composed primary keys and the save will have both conditions, id and team_id.

[Sairahcaz]

Are you using composed primary keys or composed unique constraints instead of primary id?

If yes then you can define your model to use composed primary keys and the save will have both conditions, id and team_id.

You're right that using a composite primary key like (id, team_id) can technically solve this at the DB level.

However, Eloquent doesn't natively support composite primary keys. Even if defined in the database, Laravel will still only use id when generating the WHERE clause for save().

To make this work properly, you'd need to override setKeysForSaveQuery() in the model:

protected function setKeysForSaveQuery($query)
{
    return $query->where('id', $this->id)
                 ->where('team_id', $this->team_id);
}

So yes, it’s technically possible to fix the issue with custom model logic – but the point of this bug report is that the current default behavior in updateOrCreate() is misleading and unsafe in multi-tenant contexts unless developers are aware of this Laravel quirk.

[Sairahcaz]

There is one problem. Events. The update with scopes would become mass update and events would not be triggered.

But in order for an update to happen, the row must be found in db via scopes from firstOrNew, no? So, if the scopes are applied when retrieving the row from db then why is that an issue?

Or the issue is on create rather than update?

You're right that mass updates skip model events — but in this case, updateOrCreate() does not perform a mass update.

The update happens via $model->save(), which triggers the full lifecycle: saving, updating, updated, etc. So events are not the issue here.

The core problem is that during save(), Laravel calls performUpdate() which builds its own WHERE clause using only the model's primary key (id by default), and does not include any global scopes like team_id — even though those were applied during the select phase via firstOrNew().

So even if you retrieved the model within the proper tenant scope, the subsequent UPDATE query is not scoped and may unintentionally update records outside the intended tenant.

This isn't a mass update issue — it's a scope consistency issue.

[macropay-solutions]

@Sairahcaz This is intended behavior. The save saves the model in db by its primary key (id) which should be unique even for your case. This should not include the builder scopes.

Eloquent can be extended to support composite PKs.

Demo model with composed PK:

https://github.com/macropay-solutions/laravel-crud-wizard-decorator-free-demo/blob/production/app/Models/OperationProductPivot.php

Demo service with composed PK:

https://github.com/macropay-solutions/laravel-crud-wizard-decorator-free-demo/blob/production/app/Services/OperationsProductsPivotService.php

This is your solution.
You can extend the Flight model (if that has a primary key id and the id + team_id represent a composed unique key) in a model that has the composed PK just like in the above example.

But if id is unique there is no point anyway on doing this.

EDIT.
Create will need special attention on the composite pk because it might not be applied from the scope.

[Sairahcaz]

Thanks! I fully agree that Laravel's save() works by primary key — and that’s expected behavior.

But this issue is not about wanting composite primary keys per se — it's about the inconsistency of updateOrCreate() using global scopes during the SELECT part (via firstOrNew) but not during the UPDATE (via save()), even though the model is scoped.

That means even if I retrieved a model within the tenant scope, Laravel can later update it outside that scope, unless I override setKeysForSaveQuery() or use custom logic.

Whether or not id + team_id is a key in the database is a separate topic — the core issue is the mismatch between query behavior and update behavior in updateOrCreate().

And just to clarify, Laravel explicitly states in the docs that composite primary keys are not supported:

"Composite" primary keys are not supported by Eloquent models.
– https://laravel.com/docs/11.x/eloquent#composite-primary-keys

So while it's technically possible to work around this with custom logic or third-party packages, it's not something Laravel supports or encourages natively.

That's why I opened this issue — because the current updateOrCreate() behavior is inconsistent and not obvious:

• It applies global scopes when selecting the model
• But ignores those scopes when updating the same model via save()

That disconnect is easy to miss, and potentially dangerous in scoped environments.

Thanks again for the discussion and links — but I still believe this behavior should at least be documented or made more consistent.

[macropay-solutions]

Documented yes. Thank you.

[macropay-solutions]

@Sairahcaz
FYI only.
If you will load a relation on the user in that scope you might be affected by this bug #51825