`-ing` Observer events fire after changes are persisted if `ShouldHandleEventsAfterCommit` or `$afterCommit = true` is present

[WilliamVenner]

Laravel Version

11.45.1

PHP Version

8.3.8

Database Driver & Version

No response

Description

-ing events such as updating, creating and deleting still fire after the transaction commits if ShouldHandleEventsAfterCommit is implemented or $afterCommit = true property is present on the Observer.

The documentation states that these events fire before changes are persisted, but in the case where ShouldHandleEventsAfterCommit is implemented or $afterCommit = true property is present on the Observer, these events fire after changes are persisted.

I think the documentation should at least clearly clarify this behaviour.

In my opinion -ing events should be excluded from this behaviour entirely. I don't believe there is any logical use case for -ing events to fire this way - it makes them redundant as they effectively just become -ed events.

Steps To Reproduce

1. Set up an observer for a model that implements ShouldHandleEventsAfterCommit or has $afterCommit = true property
2. Listen for -ing events
3. Trigger an -ing event
4. Inspect the model and notice that changes have been persisted

[macropay-solutions]

-ing events can be used for altering the stored data and maybe they should not be affected by the commit logic.

An example would be an updated_by_user_id column that can be populated using updating event.

Currently this can be accomplished by using 2 observers. One for -ing that does not use the after commit logic and one with after commit logic for -ed events.

Maybe this recommendation should be documented.