`$evaluateExpression` Failing When Task Runners are Enabled (N8N_RUNNERS_ENABLED=true)

[tsilva95]

Hi everyone,

I recently encountered an issue with $evaluateExpression when enabling Task Runners in n8n (setting N8N_RUNNERS_ENABLED=true). This issue disrupts workflows that rely on evaluating expressions with outputs from previous steps. Since enabling Task Runners is encouraged to prepare for future releases (where Task Runners will be mandatory), I wanted to share the details here.

I’ve also submitted a bug report on GitHub: [GitHub Issue Link]

---

Issue Details:

When Task Runners are enabled, $evaluateExpression fails to evaluate expressions that depend on the context of previous steps. Without Task Runners, the same expressions work perfectly fine.

Here’s a use case to illustrate:

Imagine a JSON object like this:

{
“property1”: “VALUE1”,
“property2”: “{{$(‘MY_PREVIOUS_WORKFLOW’).[0].id}}” // Trying to evaluate output of a previous step here
}

When Task Runners are disabled (N8N_RUNNERS_ENABLED=false), $evaluateExpression evaluates the id property from the previous step without issues. However, with Task Runners enabled, it throws an error:

TypeError: Cannot assign to read only property ‘constructor’ of object ‘#’

It appears that the new Task Runner architecture, which serializes/externalizes workflow execution processes, changes the context (that) used in expressions. As a result, workflows relying on previous step outputs break under this setting.

---

Warning from n8n:

Enabling Task Runners is highlighted as important for future releases, as running n8n without Task Runners is deprecated:

N8N_RUNNERS_ENABLED → Running n8n without task runners is deprecated. Task runners will be turned on by default in a future version. Please set N8N_RUNNERS_ENABLED=true to enable task runners now and avoid potential issues in the future. Learn more: Task Runners Documentation

Since running workflows without Task Runners will no longer be supported, resolving this issue is essential to prepare for upcoming n8n updates.

---

Steps to Reproduce:

1. Enable Task Runners by setting N8N_RUNNERS_ENABLED=true.
2. Create a workflow that evaluates an expression referencing the previous step’s output, such as:

$(‘MY_PREVIOUS_WORKFLOW’).[0].id

3. Run the workflow and observe that $evaluateExpression fails to evaluate due to context-related issues.

---

Environment:

• n8n version: 1.86.1 (Docker image)
• Node.js version: v20.19.0
• OS: Docker

---

Temporary Workaround:

For now, disabling Task Runners (N8N_RUNNERS_ENABLED=false) resolves the issue, but this isn’t ideal as Task Runners are required for future updates.

If anyone else has encountered this or found a workaround, I’d love to hear your thoughts. Otherwise, feel free to track the GitHub bug report here: [GitHub Issue Link].

Thanks!

[Mutasem]

Hello,

Can you please share an example workflow? I tested with and without task runners, and the expressions are resolving as expected.
Please note that Task Runners have been rolled out completely to all our Cloud users for a long time, so we have high confidence in this feature.

Also the expression you are sharing here looks wrong.

Corrected here

[tsilva95]

Hi there!

Thank you so much for your response regarding the issue I raised.

The problem occurs when we call the function directly inside a Code step. When attempting to use it, the function doesn’t return the expected results, as you can see in the attached evidence (screenshots/prints) provided in this reply.

Please let me know if you need any further information or clarification to help resolve this issue! I’m happy to assist in any way I can.

Thanks again for your support!

N8N_RUNNERS_ENABLED=false

N8N_RUNNERS_ENABLED=true

[Mutasem]

Thanks for sharing the example.

Sorry I completely misunderstood the problem. Will tag this as a bug internally and tackle it soon.