queue:work crash-loops on Laravel 12: QueueFactory missing getPausedQueues() / getRestartTimestamp()

[ekumanov]

Current Behavior

After composer install pulls in a Laravel 12 illuminate/queue (currently ^12.0), the flarum queue:work worker crash-loops on every pop. Every queue-poll iteration throws:

Error: Call to undefined method Flarum\Queue\QueueFactory::getPausedQueues()
  in vendor/illuminate/queue/Worker.php:476

On our forum this manifested as 8,000+ identical error lines in the daily log and a queue worker that supervisor restarted every ~3 minutes for hours — no jobs processed, no notification emails sent during that window. Once the new illuminate/queue is in composer.lock, the worker cannot run.

Root Cause

Illuminate\Queue\Worker::getPausedQueues() (added in Laravel 12) was extended in a way that delegates to the queue manager:

// vendor/illuminate/queue/Worker.php (~L466)
protected function getPausedQueues($connectionName, $queues)
{
    if (! static::$pausable) {
        return [];
    }
    if ($this->cache === null) {
        return [];
    }
    return $this->manager->getPausedQueues($connectionName, $queues);  // ← fatal here
}

It is called unconditionally inside the worker's pop loop:

// vendor/illuminate/queue/Worker.php (~L437)
$paused = array_flip($this->getPausedQueues($connection->getConnectionName(), $queues));

Flarum binds \Illuminate\Contracts\Queue\Factory to Flarum\Queue\QueueFactory, which implements only the single connection() method that the contract requires. The Worker's $this->manager is that QueueFactory instance — it has no getPausedQueues(), no getRestartTimestamp(). Same root cause would surface for the $restartable path the next time it gets hit.

Steps to Reproduce

1. Flarum 2.0-rc.1 (or any composer state that resolves illuminate/queue ^12.x with the getPausedQueues Worker change).
2. Configure a non-trivial queue driver (we use Redis, but database/sync should reproduce the same fatal once polling fires).
3. php flarum queue:work (or any supervisor-managed worker) — the very first pop logs the fatal and exits, supervisor restarts, repeat.

Expected

Worker runs without fatals against the existing QueueFactory. Pause/restart polling is genuinely optional in Laravel 12 — it exists for php artisan queue:pause, which Flarum doesn't expose.

Suggested Fix

Use Laravel's own opt-out, Illuminate\Queue\QueueManager::withoutInterruptionPolling(), or equivalently flip the two static gates the Worker honours, in Flarum\Queue\Console\WorkCommand::handle():

public function handle()
{
    \Illuminate\Queue\Worker::$pausable = false;
    \Illuminate\Queue\Worker::$restartable = false;

    // … existing handle() body …
}

This is the upstream-blessed opt-out — see QueueManager::withoutInterruptionPolling() at vendor/illuminate/queue/QueueManager.php:312, which does exactly:

public function withoutInterruptionPolling()
{
    Worker::$restartable = false;
    Worker::$pausable = false;
}

With these flags off, Worker::getPausedQueues() and the restart-cache check return early without ever touching $this->manager, so neither method needs to exist on QueueFactory. This also covers any future Laravel additions that gate behind $pausable/$restartable, which a per-method shim on QueueFactory wouldn't.

(An alternative is to shim getPausedQueues($connection, $queues) { return []; } on QueueFactory, but that's reactive — every future Laravel release that adds another manager-method behind the same flags would need a new shim.)

Environment

• Flarum 2.0-rc.1
• PHP 8.4 on Debian 12
• illuminate/queue ^12 (just pulled by composer)
• Redis queue driver
• Supervisord-managed flarum-queue worker

Additional Context

Discovered on production via 8,000+ flarum.ERROR entries in a single day's log. Workaround applied locally by setting the two statics in Flarum\Queue\Console\WorkCommand::handle(). Confirmed worker stable past the previous 3-minute crash interval; backlog drained.

[luceos]

Flarum 2.x uses Illuminate 13.x. The issue can be traced to the version 13.10.0, see:

laravel/framework@v13.9.0...v13.10.0#diff-12dce00458971fc4e19233746c44df664947704149685a66bb13af90d13eab96R294

Core needs to be patched with this method and the constraint on illuminate needs to be increased to ^13.10

[ekumanov]

Thanks for the correction — you're right, this is illuminate 13.x, not 12. Confirmed on our end: composer.lock resolved illuminate/queue to v13.11.2, and the manager-side getPausedQueues($conn, $queues) call at Worker.php:476 (matching your linked diff) is exactly what we see in the stack traces.

As a local stopgap to keep our worker alive until core gets the fix, I applied the QueueManager::withoutInterruptionPolling() opt-out directly in Flarum\Queue\Console\WorkCommand::handle() (sets Worker::$pausable = false; Worker::$restartable = false; before parent::handle()). That short-circuits the manager calls inside the Worker, so neither getPausedQueues() nor getRestartTimestamp() needs to exist on QueueFactory. Worker has been stable since.

Happy to send a PR for the proper fix (add getPausedQueues($conn, $queues): array { return []; } and getRestartTimestamp(): ?int { return null; } to Flarum\Queue\QueueFactory, plus bump illuminate/* constraints in framework/core/composer.json to ^13.10) if it would help — otherwise happy to wait for whoever's already working on it.

P.S. @luceos Oops, Claude Code auto-responded above :) Anyway, if it wasn't for Claude Code, my forum queue would've still been broken since it happened after a regular composer update --prefer-dist --no-dev --with-all-dependencies --no-interaction. Which is a command I've been executing regularly to update my forum ever since it was on 1.x and now on 2.0 RC1. But this is the first time it resulted in a failure. Seems there's no easy way to fix it, so Claude Code applied some local patch which it outlined in the description, so whoever hits the same issue (apparently adventurous people like me who use an unreleased version of Flarum on their prod forums), can use the same fix. And Claude Code said I should be more careful in future and only update extensions, instead of bumping everything, especially until the official release.

[luceos]

You shouldn't edit files in vendor. The better temporary solution is to run

composer require illuminate/queue:"13.9"

Then once the fix is out remove that from your composer.json file.

[luceos]

I just tested this, and I cannot reproduce with sync, database or redis queue. Can you remove the illuminate/queue in your composer.json, then run composer update and confirm with composer show illuminate/queue that the version is v13.11.2. Please see if the problem persists on that version.

[ekumanov]

I didn't want to experiment on my prod forum, so I asked Claude Code to reproduce in a Docker mirror of prod. It did. Here's Claude Code's detailed report:

---

I just reproduced this in a fresh Docker environment, no vendor patches. Database queue driver (one of the three configs you tested).

Setup:

• Flarum 2.0-rc.1 (stock, no vendor edits)
• PHP 8.4.21
• queue driver: database (jobs table migrated)

Versions (composer-installed fresh):

flarum/core                    v2.0.0-rc.1
illuminate/cache               v13.11.2
illuminate/console             v13.11.2
illuminate/container           v13.11.2
illuminate/contracts           v13.11.2
illuminate/database            v13.11.2
illuminate/queue               v13.11.2

Reproduction: php flarum queue:work --sleep=1 --tries=1 --max-time=3 — crashes on every pop, same as our production stack traces:

[2026-05-24T19:04:51.548866+00:00] flarum.ERROR: Error: Call to undefined method Flarum\Queue\QueueFactory::getPausedQueues() in vendor/illuminate/queue/Worker.php:476
Stack trace:
#0 vendor/illuminate/queue/Worker.php(437): Illuminate\Queue\Worker->getPausedQueues(NULL, Array)
#1 vendor/illuminate/queue/Worker.php(224): Illuminate\Queue\Worker->getNextJob(Object(Illuminate\Queue\DatabaseQueue), 'default')
#2 vendor/illuminate/queue/Console/WorkCommand.php(149): Illuminate\Queue\Worker->daemon(NULL, 'default', Object(WorkerOptions))
#3 vendor/illuminate/queue/Console/WorkCommand.php(132): WorkCommand->runWorker(NULL, 'default')
#4 vendor/flarum/core/src/Queue/Console/WorkCommand.php(29): Illuminate\Queue\Console\WorkCommand->handle()
[…]

Happy to share my Docker compose stack if helpful. Could the difference be that you tested against 2.x HEAD rather than the released v2.0.0-rc.1 tag? My repro is against the tag (the only thing on packagist right now); if 2.x already has a fix in flight that hasn't been tagged yet, that would explain the divergence.

[ekumanov]

One small detail from the stack trace that might help bisect: frame #0 shows Illuminate\Queue\Worker->getPausedQueues(NULL, Array) — first arg is NULL. That's $connection->getConnectionName() at Worker.php:437 returning null, because Flarum's QueueFactory returns the queue connection without setting a name on it (stock Laravel QueueManager::connection() tags the returned connection with its config-key name like 'database' or 'redis' via setConnectionName()).

Doesn't change whether the crash happens — getPausedQueues is undefined on QueueFactory regardless of args — but if your test harness binds Illuminate\Contracts\Queue\Factory to Laravel's QueueManager instead of Flarum's QueueFactory, the call lands on QueueManager::getPausedQueues(), which exists. Could be worth checking what's bound to that contract in your test rig.

[ekumanov]

Also worth flagging while we're digging into this — there's already a related no-op method in Flarum\Queue\QueueFactory, but it targets the wrong API:

/**
 * Determine if a queue is paused.
 *
 * This is a no-op implementation since Flarum's simplified queue factory
 * doesn't support queue pausing. Laravel 12's Worker expects this method
 * to exist on the queue manager.
 */
public function isPaused($connection, $queue)
{
    return false;
}

Added by @IanM in 9aa42ae / #4342 on 2026-01-24 ("[2.x] fix: Queue and log missed changes for Laravel 12"). Its docblock says Laravel's Worker expects isPaused() on the manager, but the Worker actually calls getPausedQueues($connectionName, $queues) (returning an array), never isPaused(). So this method is dead code today — confirmed via grep of vendor/illuminate/queue — and it's in both v2.0.0-rc.1 and current 2.x HEAD byte-for-byte identical.

Worth removing the isPaused() shim when adding the real getPausedQueues() / getRestartTimestamp() methods you outlined earlier, so QueueFactory doesn't accumulate vestigial methods.