Static state outlives the job

One static array, from one of our projects:

class Settings
{
    private static $cache = [];

    public static function get($tenantId, $key)
    {
        if (!isset(self::$cache[$tenantId])) {
            self::$cache[$tenantId] = self::load($tenantId);
        }
        return self::$cache[$tenantId][$key] ?? null;
    }
}

A reasonable per-request cache. Under PHP-FPM it died with the process. In a queue worker it lives forever.

PHP had one great architectural feature nobody put in the manual: the process died after every request. Leak memory, cache nonsense in a static, forget to close things. Did not matter. The dying process forgave everything.

Queue workers take that forgiveness away. A worker boots the framework once and processes jobs for hours in the same process. Code written under the old model misbehaves in ways that are hard to even describe in a bug tracker.

With the Settings class above: admin changes a setting, the worker keeps serving the old value for hours. Worse, memory grows with every tenant that passes through, until the process dies at the memory limit somewhere in the middle of a job. Two bugs from one innocent static.

Same story with less obvious state. An authenticated user object left in the container by job one, visible to job two. A database connection that timed out on the server side during a quiet hour, so the first job of the morning fails with “MySQL server has gone away”. An entity manager that accumulates every entity it ever saw.

What worker-safe means to me now. Job code takes dependencies explicitly and keeps state in the job, not in statics and not in singletons. Whatever per-request state the framework has is reset between jobs, most queue libraries have a hook for this. Connections are ping-checked or reconnected on error, never assumed alive. The memory limit on the worker is a safety net, and restarting workers on every deploy is not optional, because an old worker runs old code.

Test the suspicious job by running it twice in the same process. Not twice in two processes. Twice in one. The difference is exactly where these bugs live.