Queue workers (Laravel)

How Laravel queues interact with Voodflow. Redis is optional unless you choose QUEUE_CONNECTION=redis.

Laravel queues in short

QUEUE_CONNECTION in .env decides where jobs are stored until a worker processes them (see Laravel — Queues):

Connection	Need php artisan queue:work?	Notes
sync	No — jobs run immediately in the same PHP process	Handy for local tests; nothing is persisted.
database	Yes — jobs are rows in the jobs table	Works with only MySQL/Postgres; run php artisan queue:table + migrate if you have not already.
redis	Yes — jobs are stored in Redis (separate in-memory service)	Better for high throughput and Horizon; adds a Redis container/service.

What is Redis here? It is just another queue backend Laravel can use — faster than polling the DB, common in production. Voodflow does not “need Redis” unless you set QUEUE_CONNECTION=redis (or your host app does).

What Voodflow sends to the queue

Voodflow dispatches Voodflow\Voodflow\Jobs\ExecuteWorkflowJob for:

• Event workflows (listener registered by EventRegistrar)
• Manual “Run” from the flow editor (ManualTriggerNode)

Those flows create an Execution and expect a worker to call processExecution, unless QUEUE_CONNECTION=sync (job runs inline).

Not dispatched via that job (they call WorkflowExecutor directly in the current process):

• Schedule — php artisan voodflow:schedule-run runs the graph inside that CLI process
• Webhook — the HTTP request handles execution in PHP-FPM / the web worker

So: scheduler and queue worker solve different problems. For schedules you still need schedule:work or cron; see Schedule trigger.

Overrides (optional)

In Voodflow → Settings you can set a dedicated queue connection and queue name for ExecuteWorkflowJob. If left empty, Laravel’s default connection and queue apply (config/queue.php).

Local development

# If QUEUE_CONNECTION is database or redis:
php artisan queue:work

# Scheduler + queue (+ Reverb if available) in one process:
php artisan voodflow:work

Production: keep one long‑lived queue:work

Laravel only needs a process that stays up and runs queue:work (same idea as running it in Docker with restart:, a systemd unit on a VM, or whatever your host uses).

Example:

php /var/www/html/artisan queue:work --sleep=3 --tries=3 --max-time=3600

Add --queue=… only if you isolate Voodflow on a named queue.

After each deploy, refresh workers so they load new code:

php artisan queue:restart

Docker example without Redis

# .env
QUEUE_CONNECTION=database

services:
  app:
    # ...
  worker:
    build: .
    command: php artisan queue:work --sleep=3 --tries=3
    restart: unless-stopped
    volumes:
      - .:/var/www/html
    environment:
      QUEUE_CONNECTION: database

Redis + Horizon (optional)

With QUEUE_CONNECTION=redis, you can run php artisan horizon instead of plain queue:work for scaling and a dashboard — follow Laravel Horizon. This is optional and unrelated to “making Voodflow work” on a small install.

Failed jobs

When using the database (or other) driver with failures enabled:

php artisan queue:failed
php artisan queue:retry <uuid>
php artisan queue:retry all

Quick checklist

• Event / manual Run stuck? Check QUEUE_CONNECTION and that a worker is running (or use sync locally).
• Schedule never fires? Fix scheduler (schedule:work or cron), not the queue worker.
• composer run dev — if your project uses it, it may start workers + assets per its composer.json; still match the official Laravel docs for your Laravel version.