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
I'm testing jobs using ShouldBeUnique with the $uniqueFor parameter. From my understanding, $uniqueFor should prevent any other job with the same unique ID from being dispatched within the specified timeframe. However, I noticed that the lock is released immediately after the job is processed, rather than respecting the timeout period. This allows the same job to be dispatched again before the intended expiration time.
Expected Behaviour:
The lock should remain for the full $uniqueFor duration, even after the job is processed.
Actual Behaviour:
The lock is removed as soon as the job is processed, ignoring the $uniqueFor setting.
Is this the intended behaviour, or should the expiration time be enforced?
Thanks.
Steps To Reproduce
Environment Variables:
CACHE_DRIVER=databaseQUEUE_CONNECTION=database
Job Dispatch:
MyJob::dispatch(id: 1);
Job Class:
<?phpnamespaceApp\Jobs;
useIlluminate\Bus\Queueable;
useIlluminate\Contracts\Queue\ShouldBeUnique;
useIlluminate\Contracts\Queue\ShouldQueue;
useIlluminate\Foundation\Bus\Dispatchable;
useIlluminate\Queue\InteractsWithQueue;
useIlluminate\Queue\SerializesModels;
classMyJobimplementsShouldBeUnique, ShouldQueue
{
useDispatchable, InteractsWithQueue, Queueable, SerializesModels;
publicint$uniqueFor = 3600; // Unique for 1 hour/** * Create a new job instance. */publicfunction__construct(
protectedint$id,
) {}
/** * Execute the job. */publicfunctionhandle(): void
{
// Job logic here...
}
/** * The unique ID of the job. */publicfunctionuniqueId(): string
{
return"$this->id";
}
}
Observed Behaviour
After dispatching the job, the cache_locks table contains the following row:
Shouldn't the expiration time be checked before releasing the lock? Is it expected that the lock is released regardless of the job's uniqueFor timeout, or am I missing some configuration or implementation detail that would prevent this behaviour?
Thank you!
The text was updated successfully, but these errors were encountered:
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
PHP Version
8.3
Database Driver & Version
No response
Description
Hi,
I'm testing jobs using ShouldBeUnique with the $uniqueFor parameter. From my understanding, $uniqueFor should prevent any other job with the same unique ID from being dispatched within the specified timeframe. However, I noticed that the lock is released immediately after the job is processed, rather than respecting the timeout period. This allows the same job to be dispatched again before the intended expiration time.
Expected Behaviour:
The lock should remain for the full $uniqueFor duration, even after the job is processed.
Actual Behaviour:
The lock is removed as soon as the job is processed, ignoring the $uniqueFor setting.
Is this the intended behaviour, or should the expiration time be enforced?
Thanks.
Steps To Reproduce
Environment Variables:
Job Dispatch:
Job Class:
Observed Behaviour
After dispatching the job, the
cache_locks
table contains the following row:However, when the queue worker is started using:
As soon the job is processed the lock is removed from the cache looks.
Investigation
It appears that the lock is being released in
CallQueuedHandler.php
:This triggers a call to
UniqueLock.php
which usesforceRelease
:Question
Shouldn't the expiration time be checked before releasing the lock? Is it expected that the lock is released regardless of the job's uniqueFor timeout, or am I missing some configuration or implementation detail that would prevent this behaviour?
Thank you!
The text was updated successfully, but these errors were encountered: