Cache::flexible does not refresh in the background between stale period

[mnaviddoost]

Laravel Version

12

PHP Version

8.3

Database Driver & Version

No response

Description

Hi. I am using the Cache::flexible method as follows:

$now = Cache::flexible('dateeeeee17', [10, 60], function () { return Carbon::now()->toTimeString(); }); return view('test', compact('now'));

Here is the behavior I am observing:

On the initial request, I get 12:00:00.
For the first 10 seconds (the "fresh" period), the cache correctly returns the same value.
Between 10 and 60 seconds (the "stale" period), I refresh the page several times at 5-second intervals. According to the documentation, the cache should refresh in the background during this period.
However, I still keep seeing the initial value (12:00:00). The new value only appears after 60 seconds, when the cache expires.
It seems that no background refresh is happening during the stale period, contrary to what the documentation suggests.
I have tried searching for existing issues or discussions but couldn’t find anything. Any guidance or confirmation on whether this is expected behavior would be appreciated.

Thank you!

Steps To Reproduce

no steps

[miladev95]

during the stale window Cache::flexible should return the stale value immediately and trigger a refresh in the background (only one process obtains the refresh lock). If you see the value only change after full expiry, common causes are the cache driver not supporting atomic locks or the refresh being dispatched to the queue with no worker running.

file and array drivers don't support atomic locks. Check config('cache.default') / CACHE_DRIVER. Use redis, memcached or database for proper locking.
if the refresh is dispatched asynchronously, ensure a worker is running (php artisan queue:work) or set QUEUE_CONNECTION=sync for testing.

only one request can refresh. If lock acquisition fails or the callback throws, no refresh will happen.

this logs when the flexible callback actually runs so you can see whether refresh runs during the stale window.

Route::get('/test-flexible', function () {
    $now = Cache::flexible('dateeeeee17', [10, 60], function () {
        \Log::info('flexible callback ran', ['time' => now()->toTimeString()]);
        return now()->toTimeString();
    });

    return view('test', compact('now'));
});

[mnaviddoost]

@miladev95
Thanks for your response.
However, I am using the Redis cache driver and the problem still persists.

[miladev95]

A few quick checks:

1. Make sure a queue worker is running, php artisan queue:work --sleep=3 --tries=3.
2. Confirm QUEUE_CONNECTION in /.env is not sync and that config/queue.php uses an async driver (Redis or similar).
3. Add a small log inside your Cache::flexible callback to verify the refresh runs.
4. Inspect queued/failed jobs and logs: php artisan queue:failed and tail -f storage/logs/laravel.log.
5. Verify your Redis client and lock support (phpredis/predis installed) and that config/cache.php is configured to use the redis store.

If you still don’t see the log entry during the stale period, the refresh job is not being dispatched. If you see an exception in the logs, paste the trace here and I’ll help diagnose it.

[mnaviddoost]

@miladev95
Thanks for the detailed checks.

Is a queue actually used for updating the cache in this case?
If so, I should mention that I’m using Laravel Horizon, and there are no dispatched jobs at all — nothing pending or failed.

[miladev95]

Yes, Cache::flexible uses a background job to refresh during the stale window. If you’re seeing no jobs in Horizon, either the refresh job is never queued (e.g. QUEUE_CONNECTION=sync or refresh condition not hit) or it’s dispatched but failing silently.
Check QUEUE_CONNECTION in /.env is not sync.
Ensure Horizon is running: php artisan horizon:status.
Verify no failed jobs: php artisan queue:failed and check the Horizon dashboard.
Watch logs: tail -f storage/logs/laravel.log.
Confirm your cache store/locks are Redis and client is configured (config/cache.php and Redis client like phpredis).

a log inside the Cache::flexible callback and global listeners for queue events (put the listeners in app/Providers/AppServiceProvider.php boot method). This will show if a job is dispatched/processed/failed.

<?php
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Event;
use Illuminate\Queue\Events\JobProcessing;
use Illuminate\Queue\Events\JobFailed;

// 1) Log inside the flexible callback to confirm background execution
$now = Cache::flexible('dateeeeee17', [10, 60], function () {
    $val = \Carbon\Carbon::now()->toTimeString();
    Log::info('flexible refresh executed', ['time' => $val, 'context' => 'background_refresh']);
    return $val;
});

// 2) Add these listeners in `app/Providers/AppServiceProvider.php` -> boot()
//    to see queued jobs being processed or failing
Event::listen(JobProcessing::class, function (JobProcessing $event) {
    Log::info('job processing', [
        'name' => method_exists($event->job, 'resolveName') ? $event->job->resolveName() : get_class($event->job),
        'id' => method_exists($event->job, 'getJobId') ? $event->job->getJobId() : null,
    ]);
});

Event::listen(JobFailed::class, function (JobFailed $event) {
    Log::error('job failed', [
        'name' => method_exists($event->job, 'resolveName') ? $event->job->resolveName() : get_class($event->job),
        'exception' => $event->exception->getMessage(),
    ]);
});

If these produce no log lines during the stale window, the refresh job is not being queued, re-check QUEUE_CONNECTION, cache store settings. If you see a failed job log, trace exception and Horizon output for diagnosis.

[mnaviddoost]

@miladev95
According to the Laravel documentation, flexible uses the defer function, not the queue. Even so, is it still necessary to check the queue settings?
In a fresh Laravel installation, this problem doesn’t occur.

[crynobone]

Moved this to discussion as the problem didn't occur in a fresh installation. I believe this is something specific the the application.

[oor30]

I was experiencing the exact same issue after upgrading an older Laravel project to Laravel 12.

In my case, adding the following middleware fixed it.

In app/Http/Kernel.php, I added InvokeDeferredCallbacks to the web middleware group:

protected $middlewareGroups = [
    'web' => [
        \Illuminate\Foundation\Http\Middleware\InvokeDeferredCallbacks::class,
    ],
];

After this change, the problem was resolved.

[georgebuilds]

The root cause is that the InvokeDeferredCallbacks middleware is missing from your stack

Cache::flexible uses Laravel's defer() helper internally, which schedules a closure to run after the HTTP response is sent (it's not a queued job in the traditional sense, so Horizon will never show it)

For defer() to work, InvokeDeferredCallbacks middleware must be present in your middleware stack. Fresh Laravel 11/12 installs include it automatically, but projects upgraded from Laravel 10 or earlier often still have a Kernel.php, which overrides the default stack without this middleware (which is exactly why it works in a fresh install but not yours).

Fix for apps with app/Http/Kernel.php (upgraded projects):

protected $middlewareGroups = [
    'web' => [
        \Illuminate\Foundation\Http\Middleware\InvokeDeferredCallbacks::class,
        // ... rest of your middleware
    ],
];

Fix for apps using bootstrap/app.php (Laravel 11+ style):

->withMiddleware(function (Middleware $middleware) {
    $middleware->web(prepend: [
        \Illuminate\Foundation\Http\Middleware\InvokeDeferredCallbacks::class,
    ]);
})

Once the middleware is present, the stale-period background refresh should work as expected. No queue worker or Horizon configuration should be needed