Skip to content

Conversation

juliusvdijk
Copy link
Contributor

This PR addresses #55610 by updating CacheSchedulingMutex to use the lock connection instead of the default cache connection when acquiring a mutex. This mirrors the existing behavior of CacheEventMutex and ensures consistency.

To maintain API compatibility, I replicated the locking logic used in CacheEventMutex.

In our production environment, the default cache connection is not using the same instance for all servers, while the lock connection is. As described in the referenced issue, this leads to race conditions unless a workaround (defining a separate store) is implemented. The current behavior is unintuitive and, in my view, should be corrected even though a workaround exists.

Considerations

  • The main trade-off is a small amount of code duplication.
  • The change remains fully backwards compatible:
    • The keys used to acquire the locks are unchanged between the current and proposed implementations.
    • This only affects users who have configured a separate lock connection and are running multiple application versions concurrently. In that edge case, commands may run on multiple servers, depending on how connections are set up.

@juliusvdijk juliusvdijk changed the title CacheSchedulingMutex should use lock connection [12.x] CacheSchedulingMutex should use lock connection Jul 29, 2025
@taylorotwell taylorotwell marked this pull request as draft August 3, 2025 15:32
@taylorotwell taylorotwell marked this pull request as ready for review August 3, 2025 15:33
@taylorotwell taylorotwell merged commit 767f9b7 into laravel:12.x Aug 3, 2025
62 checks passed
taylorotwell pushed a commit that referenced this pull request Aug 11, 2025
crynobone added a commit that referenced this pull request Aug 12, 2025
* [11.x] Correct how base options for missing config files are preloaded (#56216)

* Formatting

* Add breaking test to demo config array has been incorrectly keyed with numbers

* Correct how base options for missing config files are preloaded

* fix: AsCommand properties not being set on commands (#56236)

The Symfony Command uses the AsCommand attribute to set properties on
the command class. However, the properties are only set if they are
identical to an empty string. The Laravel Command class overrides the
properties and removes the default value which causes the properties to
be null and therefore not set.

* update trust proxy

* add trust proxy

* [12.x] Consistent use of `mb_split()` to split strings into words (#56338) (#56617)

* consistent use of mb_split to split strings into words with multi-byte support

* The $pattern argument doesn't use /pattern/ delimiters, unlike other regex functions such as preg_match

Co-authored-by: Sebastian Hädrich <[email protected]>

* fix: CacheSchedulingMutex should use lock connection (#56472) (#56614)

Co-authored-by: Julius van Dijk <[email protected]>

* Test Improvements

- Fix integration with PHPUnit 12.3.4
- Fix PHPStan

Signed-off-by: Mior Muhammad Zaki <[email protected]>

* Apply fixes from StyleCI

* wip

Signed-off-by: Mior Muhammad Zaki <[email protected]>

* wip

Signed-off-by: Mior Muhammad Zaki <[email protected]>

* wip

Signed-off-by: Mior Muhammad Zaki <[email protected]>

* wip

Signed-off-by: Mior Muhammad Zaki <[email protected]>

---------

Signed-off-by: Mior Muhammad Zaki <[email protected]>
Co-authored-by: Jonathan Goode <[email protected]>
Co-authored-by: Caleb White <[email protected]>
Co-authored-by: Taylor Otwell <[email protected]>
Co-authored-by: Graham Campbell <[email protected]>
Co-authored-by: Sebastian Hädrich <[email protected]>
Co-authored-by: Julius van Dijk <[email protected]>
Co-authored-by: StyleCI Bot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants