[BUG] JavaScript Code nodes fail in production when using queue mode with external task runners

[nazarsavorona]

Description

When deploying n8n using this repository’s deployment scripts with queue mode and external task runners, JavaScript Code nodes fail to execute in production.

The same workflows work in non-production or manually configured setups, but consistently fail when deployed via this repository’s production configuration. Other node types continue to work as expected.

This strongly suggests an issue in how the deployment scripts configure or wire external task runners in production.

Steps to Reproduce

1. Deploy n8n using this repository’s deployment scripts.
2. Use the default/production-oriented configuration (queue mode enabled, external task runners).
3. Create or import a workflow containing a JavaScript Code node.

4. Wait workflow to run in production mode.
5. Observe that the Code node fails while other nodes succeed.

Error message:

Task request timed out after 60 seconds
Your Code node task was not matched to a runner within the timeout period. This indicates that the task runner is currently down, or not ready, or at capacity, so it cannot service your task.

If you are repeatedly executing Code nodes with long-running tasks across your instance, please space them apart to give the runner time to catch up. If this does not describe your use case, please open a GitHub issue or reach out to support.

If needed, you can increase the timeout using the N8N_RUNNERS_TASK_REQUEST_TIMEOUT environment variable.

Expected Behavior

JavaScript Code nodes should execute successfully in production when using:

• queue mode
• external task runners

Behavior should be consistent with development or manually configured deployments.

Actual Behavior

JavaScript Code nodes fails to execute due to time out.

Environment

Host OS

• Ubuntu 24.04.3 LTS (noble)
• Kernel: 6.8.0-79-generic
• Architecture: x86_64
• RAM: 15 GiB (no swap)
• Disk: 150 GB (≈47 GB free)

Docker

• Docker Engine: 29.1.3
• Docker Compose: v5.0.0

Additional Context

• The issue occurs consistently on clean installs.
• No custom patches were applied to n8n or the runner images.
• The same workflows work when executed manually in n8n via web UI.

Possible Solution

It would be helpful to revisit the orchestration of external task runners in the deployment scripts, especially for queue mode and production deployments.

Please consider reviewing the current setup against the official n8n documentation for task runners:

https://docs.n8n.io/hosting/configuration/task-runners/

In particular, verifying that the generated configuration aligns with the documented expectations around external runners, brokers, and workers may help identify the root cause.

[freddy-schuetz]

Quick fix pushed.

Root cause: Upstream n8n bug - internal "JS Task Runner" spawns despite N8N_RUNNERS_MODE=external and intercepts tasks. External runner never receives task offers.

Workaround: Disabled queue mode (EXECUTIONS_MODE=regular). Code Nodes work now.

To update:

cd ~/ai-launchkit
sudo bash ./scripts/update.sh

Proper queue mode with separate runner sidecars per worker will be implemented later once n8n fixes the upstream issue.

Let me know if it works!

[nazarsavorona]

Thanks: the fix helped and we’re no longer blocked on the original issue.

However, we still see n8n-runner (n8nio/runners) going “unhealthy” / cycling. The logs look like it’s likely fine but not actually connected to the broker / not receiving tasks:

• “Waiting for task broker to be ready…”
• “Waiting for task offer to be accepted…”
• “Runner process exited on idle timeout”

So it seems the runner comes up, but n8n isn’t handing it tasks or the broker config isn’t reachable, and it idles out and restarts (doesn’t look like a disk issue).

Would you prefer we keep this issue open until the upstream n8n runner/broker bug is addressed or clarified, or close it as “workaround confirmed” and track the runner/broker connectivity separately?