Checking Unique Lock Release Entries in Laravel 13.36 and 13.37

A unique lock is only as dependable as the code path that releases it. If a lock stays in place after the work it guarded has stopped, a later dispatch of the same job or listener can be refused. The two release lists contain several entries aimed at exactly this problem. They cover database transaction rollbacks, failed queue pushes, a testing fake, and a race between two scheduling guards. This article goes through those entries and marks where the source material stops.

What the Source Material Contains #

The source for this analysis is the list of entries in each release. Every entry has a title, an author, a pull request number and a date. The source does not include diffs, reproduction steps, exception types, stack traces or timing measurements. That limits what can be claimed. An entry title tells you the maintainers changed something in a named path. It does not tell you what happened before the change, how often the path ran, or which applications were affected.

The dates in the source metadata are 2026-10-13 for v13.36.0 and 2026-10-16 for v13.37.0. Both pages were retrieved on 2026-10-16. Any statement about who is affected is therefore an inference from the title wording. Any suggested action is a test to run in your own environment, not a step the notes recommend.

Key Changes at a Glance #

The Transaction Rollback Entry in 13.36 #

The earliest lock-related entry appears in Release v13.36.0. Its title reads "Fix unique queued listener locks not being released when the transaction is rolled back" (#61974). The title names three things: unique queued listeners, lock release, and transaction rollback. It does not say how the lock was acquired, what the rollback path looked like before the change, or whether unique jobs were involved in the same way.

Rollbacks are a normal part of database-backed applications. Validation failures, constraint violations and deliberate rollbacks all end a transaction without committing its work. If your code dispatches unique listeners from inside a transaction, the rollback path is the first place to test. A reasonable check is to run a rolled-back transaction that contains a unique listener dispatch, then confirm that a later dispatch of the same listener is accepted. The notes do not promise that outcome, so the check should be run against your own code on the version you plan to deploy.

Push Failures for Jobs and Listeners in 13.37 #

The Release v13.37.0 notes contain two entries about push failures. "Release the unique lock when pushing a job to the queue fails" (#62010) covers jobs. "Release the unique lock when pushing a queued listener fails" (#62045) covers queued listeners. The two titles describe the same action in the same kind of failure: a push to the queue that does not complete.

The notes do not explain how a push failure is detected, which exceptions are involved, or what the lock looked like in the failing case. The safest verification is therefore a direct test. Make the queue push fail during a dispatch, clear the failure, then dispatch the same unique job or listener again. If the second dispatch is refused, the lock was not released in your environment, and you should investigate before depending on the upgrade.

Applications that dispatch unique jobs from web requests should give this check priority. A push failure during a request is a realistic production event. A stuck lock is hard to notice from request logs alone, because the request itself may appear to have succeeded. The titles do not indicate how often this path runs in your application, so measure it in your own code rather than assuming it is rare.

The Queue Fake Entry Needs a Careful Reading #

The v13.37.0 notes also include "Release unique queued listener locks in Queue::fake()" (#62025). This is the entry most easily misread. Queue::fake() is a testing fake, not a production dispatch path. The entry concerns how the fake handles unique queued listener locks. The title does not describe the earlier behaviour, and it does not say that any test depended on a lock persisting under the fake. Neither point should be assumed.

The useful step is to review your own tests. Look for suites that fake the queue, dispatch unique queued listeners, and then assert on lock state or on whether a second dispatch is accepted. Run those suites on the upgraded version and note any change in outcome. If a test changes result, the failure reveals an assumption in the test. Understand that assumption before changing the test, because the release notes give no basis for deciding in advance which side is correct.

A related entry, "Respect faked Sleep in limiter block() timeout" (#62017), is also in v13.37.0. The title says the limiter's block timeout now respects faked sleep. Teams that fake time to keep rate-limited job tests fast should re-run those tests and compare durations and outcomes with a previous run. The notes do not say what the difference will look like, so the comparison is the only reliable evidence you will have.

Overlap Guards: onOneServer and withoutOverlapping #

The v13.37.0 notes include "Fix race condition with jobs using both onOneServer() and withoutOverlapping()" (#62007). The title names both guards and describes a race between them. The two guards address different concerns. One limits execution to a single server, and the other stops a new run from starting while an earlier run is still in progress. Using both on a multi-server deployment is a plausible setup, and a race between them is the kind of problem that appears only under real concurrency.

The source does not describe the trigger, the timing, or how often the race occurred, so you cannot tell from the notes which schedules were affected. The practical response is to list every scheduled task and queued job that combines the two guards. Then confirm overlap behaviour on a staging environment with the same server count as production. If you keep logs of past runs, look for overlapping executions of those tasks, but treat any frequency estimate as unverified until you have checked it.

Redis Clusters and Worker Behaviour in 13.36 #

The Release v13.36.0 notes contain several Redis and worker entries. "Rebuild the phpredis client when no cluster node is reachable" (#61911) and "Release persistent phpredis socket before rebuilding client" (#61919) both concern how the phpredis client is replaced when a cluster node cannot be reached. The second title suggests the persistent socket is released before the rebuild. The notes give no recovery times and do not describe the failure in detail, so expectations about recovery should come from staging tests.

Several worker entries appear in the same release. "Allow queue workers to flush sticky connections between jobs" (#61915) changes how sticky connections are handled between jobs. "Adjust Worker to not call the killback twice" (#61940) changes how a callback is invoked in the worker. The notes also add queue and connection details to the JSON output of the work command, for paused and resumed events (#61896) and for stop events (#61858). If your monitoring or deployment tooling parses that output, review the parser before upgrading.

The v13.36.0 notes also include "Make the worker timed out exit code reachable" (#61623). That entry is labelled [12.x] in the notes, so it should be read as the notes present it. Do not assume it is a 13.x-only change. Check whether it applies to the version you run, and read the entry in the full release notes rather than relying on this summary.

Batching Redis queue notification pushes (#61965) is the one performance-oriented title in this group. The notes give no throughput figures, so treat it as a behaviour change to measure rather than a guaranteed improvement.

Entries Outside the Lock Theme #

Both release lists contain many entries unrelated to unique locks. From v13.37.0, examples include "Fix N+1 queries when including nested JSON:API relationships" (#62000) and "Fix restore() failing on soft delete queries with joins" (#61998). From v13.36.0, "Fix JSON path updates being lost after reading an Attribute accessor" (#61962) is one example. This article does not analyse these, so teams that rely on those features should read the notes directly.

The v13.37.0 notes also add a --queue option to queue:failed (#61971) and allow queue:forget to accept multiple IDs (#61901). These are operator changes rather than lock fixes. Scripts that automate queue recovery should still be reviewed, because they now sit alongside the lock changes in the same release.

What the Titles Do and Do Not Establish #

Several changes across the two releases concern unique locks. They appear in the transaction rollback path in v13.36.0, and in the job push path, the listener push path and the queue fake in v13.37.0. That is an observation about the titles. It is not evidence of a single underlying defect, and the notes do not connect these entries to each other. Treat the grouping as a way to plan tests, not as a claim about maintainer intent.

The source material gives no benchmarks, reproduction steps or timing data. That is enough to decide what to test, but not enough to predict production impact. Confirm each behaviour in your own environment before rolling either release out widely, and treat any detail the notes do not state as a hypothesis.

Upgrade Checklist #

1. Read the full Release v13.36.0 notes, and note which entries are labelled [12.x] so you do not treat them as 13.x-only changes.
2. Read the full Release v13.37.0 notes, which contain the push-failure lock entries, the queue fake entry, the limiter entry and the onOneServer() and withoutOverlapping() entry.
3. List every unique job, unique queued listener and scheduled task in your application, and mark any that use withoutOverlapping() or onOneServer().
4. Identify every unique listener dispatch that happens inside a database transaction, and note which of those transactions can roll back.
5. Write a test that forces a job push failure, clears it, and checks whether the same unique job can be dispatched again.
6. Write a test that forces a queued listener push failure and repeats the same check for listeners.
7. Write a test that rolls back a transaction containing a unique listener dispatch, then confirms whether a later dispatch is accepted.
8. Review tests that use Queue::fake(), faked sleep or rate-limited work, and compare their results on the upgraded version with a previous run.
9. If you run Redis queues on phpredis clusters, rehearse a node-unreachable scenario in staging and observe how workers recover.
10. Check any tooling that parses the queue:work JSON output, since the notes add queue and connection fields.
11. Deploy to a canary worker pool first, review failed jobs before widening the rollout, and only proceed once the checks above pass.