Stale configuration, cache, and queue-worker behavior

Understand the likely causes

• Typical causes are cached configuration built for different inputs, env lookups outside configuration files, an unrestarted long-lived worker, tenant-unsafe cache keys, stale serialized job assumptions, and confusion between route/view caches and application data cache. Clearing everything can destroy useful state or locks without addressing the cause.

1. Identify which state is stale and who owns it

Name the layer: configuration repository, generated configuration artifact, route definitions, compiled views, business cache entry, or a running worker’s memory. Compare a small safe value under the intended process and release, not only the developer’s shell. A queue worker may have loaded code and configuration before a file changed. A cache hit can also come from an incorrect shared key rather than old configuration. Keep actor and organization scope explicit and avoid using production cache flushes as a diagnostic experiment. Reproduce with synthetic keys in an isolated store first.

2. Read configuration through its documented boundary

Keep environment reads in configuration files and application reads through config values. Once configuration is cached, the environment-file loading contract differs from an uncached request; do not assume env calls elsewhere will keep reading a recently edited file. Validate booleans, required values, and driver names deliberately. The local repository example models a worker holding an earlier snapshot while the current repository changes. It does not run a worker, load an environment file, generate a cache artifact, or establish what an actual deployment process has loaded. Use it to reason about ownership, not as production evidence.

<?php
declare(strict_types=1);
require __DIR__ . '/vendor/autoload.php';
$config = new Illuminate\Config\Repository(['exports' => ['enabled' => false], 'queue' => ['default' => 'sync']]);
$workerSnapshot = $config->all();
$config->set('queue.default', 'database');
echo $config->get('exports.enabled') === false ? "disabled\n" : "enabled\n";
echo $workerSnapshot['queue']['default'], ' ', $config->get('queue.default'), PHP_EOL;

disabled
sync database

3. Reconcile worker lifecycle and job compatibility

For a real authorized release, follow its documented worker lifecycle procedure and verify the process actually uses the intended build. Long-lived workers need deliberate reset and restart behavior; changing a file is not proof running code changed. Preserve compatibility with already queued payloads, and make retries safe through idempotent effects. A worker timeout or lost acknowledgement can cause repeat delivery, so restarting is not an explanation for duplicate writes. Inspect safe job identifiers and failure categories without exposing payload secrets. No administrative restart or real queue operation is performed by this guide.

4. Invalidate the narrow state under a reviewed plan

Choose invalidation according to the stale layer and application release contract. Data-cache keys need actor/tenant scope, size or lifetime rules, and invalidation after the relevant committed change. Locks, idempotency receipts, and session data must not be casually treated as disposable presentation cache. Verify view and route build artifacts separately from business data. Prefer a synthetic reproducer and a concrete proposed change over broad cache-clearing commands. When testing fakes, state which real store, worker delivery, and deployment assumptions remain unverified rather than treating local success as a complete operational fix.

Keep it from recurring

• Document build-time configuration inputs, worker lifecycle, cache ownership, and payload compatibility as one release contract. Use targeted invalidation and safe diagnostics. Keep a bounded synthetic test for retries and tenant-separated keys whenever configuration, cache, or queued-job behavior changes.