`Queue::fake()` does not release unique job locks between tests

[mewejo]

Laravel Version

12.49.0

PHP Version

8.5.2

Database Driver & Version

Queue running via Valkey

Updated Summary

Queue::fake() intermittently fails to capture jobs dispatched via Job::dispatch(), but the behavior is no longer clearly attributable to PHP 8.5 or destructor timing changes.

Further investigation suggests the issue is more closely related to jobs implementing ShouldBeUnique, combined with persistent cache/lock state between test runs. The failure is non-deterministic: tests may pass on first execution and fail on subsequent runs unless the underlying cache (for example Redis/Valkey) is flushed. Changing the job’s uniqueId() or clearing Redis in setUp() consistently restores passing behavior.

The problem reproduces on older environments as well (PHP 8.4 with Laravel 12.27.1), indicating it likely predates the PHP 8.5 upgrade and may have gone unnoticed due to clean CI environments masking stale uniqueness locks locally.

At this point, the core issue appears to be that uniqueness locks are persisting across test runs in a way that prevents PendingDispatch::shouldDispatch() from allowing the job to be queued, causing Queue::fake() assertions to report zero dispatched jobs even though dispatch logic is executed.

[marius-ciclistu]

Calling manually ->__destruct() fixes it?

[mewejo]

No that doesn't fix it. Digging some more, it might be related to the job being ShouldBeUnique.

If I edit \Illuminate\Foundation\Bus\PendingDispatch::shouldDispatch to return true all the time, the test passes fine.

I am running this test using Valkey as the cache/lock store.

[mewejo]

If I change the cache store to file, the issue doesn't happen and the test passes.

[mewejo]

There's some sort of test smell. If I change the uniqueId on the job and run the test, it passes. If I run it again, it fails.

[mewejo]

If I change the cache store to file, the issue doesn't happen and the test passes.

Turns out the store isn't the reason. Since discovering the last comment info, subsequent tests on file also fail.

[mewejo]

Putting app('redis')->flushall(); into tests setUp() fixes it, but this didn't used to be necessary.

I believe we were on v12.27.1 before updating.

[mewejo]

Downgrading back to PHP 8.4 & Laravel 12.27.1, the problem persists. It could be that we just never ran this test locally more than once, and CI is fresh each time... so it's probable this is completely unrelated to the PHP 8.5 upgrade.

[marius-ciclistu]

The lock is not released in your tests.

[mewejo]

Yes that's the conclusion I've come to. But I'd argue that isn't the responsibility of the developer, adding a tearDown() to clean up the framework acquiring locks.

[marius-ciclistu]

Look at the ttl of that lock.

[mewejo]

The job doesn't have a uniqueFor on it, so it's passing 0 in \Illuminate\Bus\UniqueLock::acquire.

As we're dealing with fake data, the job/lock should be finished/released once the test finishes.

[marius-ciclistu]

0 is indefinite

[mewejo]

Does Laravel never intend for you to run a ShouldBeUnique job test twice?