Quick Diagnosis
We cover this in detail in the n8n Queue Mode Errors Guide
| Symptom | Log excerpt | Affected n8n version |
|---|---|---|
| Workflow hangs after first retry | 2024-03-12 07:31:45 – Error: Worker process died unexpectedly | 0.174 – 0.190 |
| “Queue processing stopped” message in UI | Queue stopped: No active workers | 0.174 – 0.190 |
Missing queueMode flag in settings.json after restart |
queueMode: undefined | 0.174 – 0.190 |
Fix – Upgrade to ≥ 0.191 or install the back‑ported patch (npm install n8n@0.191.0) and restart the service.
EEFA note: In production a dead‑locked queue blocks downstream integrations (webhooks, API calls) and can breach SLAs. Test the fix in staging before rolling out.
1. Confirm you’re on a vulnerable version
If you encounter any n8n queue mode unsupported node version resolve them before continuing with the setup.
Why Knowing your version tells you whether the bug applies.
1.1. Check the version (npm / Node)
n8n --version
1.2. Check the version (Docker)
docker exec <container_name> n8n --version
| Detected version | Bug present? |
|---|---|
| 0.174 – 0.190 | ✅ Yes |
| 0.191 – 0.210 | ❌ No |
| 0.211+ | ❌ No |
If you fall in the range, continue with the upgrade steps.
2. Upgrade Path: Step‑by‑step
If you encounter any n8n queue mode unsupported redis version resolve them before continuing with the setup.
2.1. Backup current configuration
| Item | Command / Action |
|---|---|
Settings file (.n8n/settings.json) |
cp ~/.n8n/settings.json ~/.n8n/settings.json.bak |
| SQLite database | sqlite3 ~/.n8n/database.sqlite “.backup ‘database.backup’” |
| Docker volume (if used) | docker run –rm -v n8n-data:/data -v $(pwd):/backup alpine cp -r /data /backup |
EEFA warning: Skipping backups can make rollback impossible after a failed migration.
2.2. Choose your upgrade method
| Method | When to use |
|---|---|
| npm (self‑hosted) | Direct Node.js runtime |
| Docker pull | Official n8nio/n8n image |
| Kubernetes Helm chart | Managed K8s deployment |
npm upgrade
- Stop the running service
pm2 stop n8n # or systemctl stop n8n.service
- Install the fixed version
npm install n8n@0.191.0
- Verify the upgrade
n8n --version # should output 0.191.0
- Restart the service
pm2 start n8n # or systemctl start n8n.service
Docker upgrade
- Pull the patched image
docker pull n8nio/n8n:0.191.0
- Stop and remove the old container
docker stop $(docker ps -q --filter "ancestor=n8nio/n8n") docker rm $(docker ps -a -q --filter "ancestor=n8nio/n8n")
- Run the new container
docker run -d \ --name n8n \ -p 5678:5678 \ -v ~/.n8n:/home/node/.n8n \ n8nio/n8n:0.191.0
Helm upgrade
helm repo update helm upgrade n8n n8n/n8n \ --set image.tag=0.191.0 \ --namespace workflow
2.3. Post‑upgrade validation
- Confirm version –
n8n --version→0.191.0 - Run a failing test workflow (e.g., a
Setnode with an invalid expression). Ensure the retry fires and the queue keeps processing. - Check logs – no “Worker process died” entries should appear.
3. Temporary workaround – Back‑ported patch
When a full upgrade isn’t possible (strict change‑control), install the community patch:
npm install n8n@0.190.3-patch-queue-bug
EEFA caution: Patches are unofficial. Use only as a stop‑gap and schedule a full upgrade within 30 days.
4. Preventing recurrence – Best‑practice checklist
| Practice | Why it matters |
|---|---|
Pin a minimum version ("n8n": ">=0.191 <0.210") |
Guarantees you stay above the buggy range. |
Enable health‑checks (/healthz endpoint) in Docker/K8s |
Detects dead workers before they block the queue. |
| Automated regression testing for retry logic | Catches similar bugs before they reach production. |
Monitor queue length (GET /rest/v1/queue) |
A sudden drop to zero signals a dead‑lock. |
| Use the “latest stable” tag only in non‑critical environments | Prevents accidental downgrades during docker pull. |
6. Frequently Asked Questions
| Question | Answer |
|---|---|
Do I need to change settings.json after upgrade? |
No. The queueMode flag remains unchanged; only the worker implementation is updated. |
| Will the upgrade cause downtime? | Minimal. Stop → upgrade → start typically takes < 30 seconds. Use a rolling update in Kubernetes for zero‑downtime. |
| Can I revert if something goes wrong? | Yes. Restore the backed‑up settings.json and database, then reinstall the previous version (npm install n8n@0.188.0). |
Conclusion
The legacy queue‑mode bug affects n8n 0.174‑0.190 by dead‑locking the internal worker pool after the first retry. Upgrading to 0.191 (or later) restores reliable retry behavior and eliminates workflow stalls. Always back up configuration, validate the upgrade with a failing workflow, and adopt the checklist above to keep your automation pipeline resilient in production.
