You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When scheduling events in App\Console\Kernel::schedule(), and having an event not overlap itself for M minutes, if the event takes too long and is overlapped but completes first, it releases the mutex that is owned by the newer event, allowing the newer event to be overlapped immediately regardless of M.
Steps To Reproduce
Schedule a command (Event-X)
Have the command not overlap itself for M minutes; it holds a mutex for M minutes.
Command takes longer than M minutes to complete, mutex expires.
Command is re-run (Event-Y), overlapping Event-X (this is fine), and Event-Y now has the mutex.
Event-X completes, and CacheEventMutex::forget()force-releases Event-Y's mutex, which may still be running (this is not fine).
Event-Z can now immediately overlap Event-Y, regardless of M
Solution:
CacheEventMutex::create()must provide an $owner to the lock, or retrieve the owner after creation. This prevents a random identifier from being used during lock creation and then immediately lost. Where this value lives can be discussed. It only needs to exist in the current runtime.
CacheEventMutex::forget()must not force-release if an owner is already known from create(). This allows ScheduleClearCacheCommand to still force-release by not giving one.
ScheduleFinishCommand should accept an owner identifier to ensure that the owners are the same when attempting mutex release for background jobs. The owner, as determined in the same runtime, should be given by CommandBuilder::buildBackgroundCommand().
Failure to release upon job completion may be silent; the event is done, and overlap was allowed, no exception is necessary when another process holds the mutex.
The text was updated successfully, but these errors were encountered:
CacheEventMutex::forget() should use LockProvider::restoreLock() for release() when an owner is known, since that's meant for blind/unforced lock-resumption across sequential processes (or so I believe from what I can find about it on the net, it's not really documented).
As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.
If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.
Laravel Version
11.26.0
PHP Version
8.2.24 (irrelevant)
Database Driver & Version
SQLite 3.37.2 (irrelevant)
Description
When scheduling events in
App\Console\Kernel::schedule()
, and having an event not overlap itself forM
minutes, if the event takes too long and is overlapped but completes first, it releases the mutex that is owned by the newer event, allowing the newer event to be overlapped immediately regardless ofM
.Steps To Reproduce
M
minutes; it holds a mutex forM
minutes.M
minutes to complete, mutex expires.CacheEventMutex::forget()
force-releases Event-Y's mutex, which may still be running (this is not fine).M
Solution:
CacheEventMutex::create()
must provide an$owner
to the lock, or retrieve the owner after creation. This prevents a random identifier from being used during lock creation and then immediately lost. Where this value lives can be discussed. It only needs to exist in the current runtime.CacheEventMutex::forget()
must not force-release if an owner is already known fromcreate()
. This allowsScheduleClearCacheCommand
to still force-release by not giving one.ScheduleFinishCommand
should accept an owner identifier to ensure that the owners are the same when attempting mutex release for background jobs. The owner, as determined in the same runtime, should be given byCommandBuilder::buildBackgroundCommand()
.The text was updated successfully, but these errors were encountered: