8000 onOneServer() locks are not stored on lock_connection · Issue #55610 · laravel/framework · GitHub
[go: up one dir, main page]
Skip to content

onOneServer() locks are not stored on lock_connection #55610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
mortenscheel opened this issue Apr 30, 2025 · 5 comments
Open

onOneServer() locks are not stored on lock_connection #55610

mortenscheel opened this issue Apr 30, 2025 · 5 comments
Labels
help wanted

Comments

@mortenscheel
Copy link

Laravel Version

12.10.2

PHP Version

8.3.20

Database Driver & Version

No response

Description

Context

In config/cache.php you can define a separate connection to use for locks:
https://github.com/laravel/laravel/blob/f6e4638ee6ca1cd40aa7c56311d89ea3d91a24f8/config/cache.php#L74-L78

This makes it possible to run cache:clear without losing mutexes and atomic locks.
The lock_connection is used when calling

  • Cache::lock(...)->get()
  • Schedule::command(...)->withoutOverlapping()

It might be used in other contexts too, but those are the ones I'm aware of.

The problem

Schedule::command(...)->onOneServer() creates the lock on the regular cache connection via

framework/src/Illuminate/Console/Scheduling/CacheSchedulingMutex.php

Lines 41 to 46 in bcc9220

public function create(Event $event, DateTimeInterface $time)
{
return $this->cache->store($this->store)->add(
$event->mutexName().$time->format('Hi'), true, 3600
);
}

Which means that cache:clear will wipe those locks and allow another server to pick up the task.

Thoughts

I'm not familiar enough with the source to send a PR, and I don't know if there's a good reason for this behavior. Naively I would assume that onOneServer() should use CacheEventMutex in stead of CacheSchedulingMutex(which is apparently only used in this context).

Steps To Reproduce

  1. Use a cache driver with a separate lock_connection
  2. Configure a scheduled job with onOneServer(), which calls sleep(60).
  3. Run schedule:run
  4. Observe where the lock is stored.
@mortenscheel
Copy link
Author

Some people are suggesting complicated workarounds for this issue: https://stackoverflow.com/questions/79183842/laravel-ononeserver-method-of-task-scheduler-break-with-php-artisan-cacheclea

@crynobone
Copy link
Member

framework/src/Illuminate/Foundation/Console/Kernel.php

Lines 312 to 314 in e333cc8

return $this->app['config']->get('cache.schedule_store', Env::get('SCHEDULE_CACHE_DRIVER', function () {
return Env::get('SCHEDULE_CACHE_STORE');
}));

Laravel uses this value.

@github-actions GitHub Actions
Copy link
github-actions bot commented May 7, 2025

Thank you for reporting this issue!

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.

Thank you!

@mortenscheel
Copy link
Author

@crynobone as far as I can see, that just determines which cache store to use. It still won't use that store's lock_connection.

Of course you could define a dedicated cache store and use it via this undocumented environment variable, but I don't see why that should be necessary when we already use lock_connection for all the other lock types. It just seems inconsistent. Maybe there's a good reason, but lock_connection isn't documented at all, so it's hard to say what it's actually meant for.

@rafa-acioly
Copy link

@crynobone So if I need to use a redis on my schedule cache I can define

// config/cache.php

return [
    'schedule_store' => 'redis'
];

or set the SCHEDULE_CACHE_STORE env var with redis?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@crynobone @mortenscheel @rafa-acioly
0