Possible bug with $execution.mode

[JohnDoe]

Describe the problem/error/question

1. problem is that when running a workflow with “execute workflow” trigger the sub-workflow is always running with $exectuion.mode = production.
   I couldn’t find if this is a “feature” but for me it is confusing that is why I wanted to ask you.

Workflow which was run as a test calls the same workflow but through the other trigger but this time the mode is production

2. problem I found while looking in above situation seems to be related to UI:
   While running a workflow through production URL form:
   
   
   
   In the next step I see contradicted data
   
   
   
   Same problem when its run through scheduler trigger:
   
   

Please share your workflow

Share the output returned by the last node

[
  {
    "args": {
      "mode": "production"
    },
    "headers": {
      "host": "postman-echo.com",
      "x-request-start": "t1746788153.408",
      "connection": "close",
      "x-forwarded-proto": "https",
      "x-forwarded-port": "443",
      "x-amzn-trace-id": "Root=1-681ddf39-1f72b1c547534d176f2fb41f",
      "accept": "application/json,text/html,application/xhtml+xml,application/xml,text/*;q=0.9, image/*;q=0.8, */*;q=0.7",
      "user-agent": "axios/1.8.2",
      "accept-encoding": "gzip, compress, deflate, br"
    },
    "url": "https://postman-echo.com/get?mode=production"
  }
]

Information on your n8n setup

• n8n version: 1.90.2
• Database (default: SQLite): SQLite
• Running n8n via (Docker, npm, n8n cloud, desktop app): docker

[King_Samuel_David]

Hey John,

I would assume this happens because sub-workflows triggered via the “Execute Workflow” node always run in production mode, regardless of how the parent was started (manual, schedule, webhook, etc.).

It’s not a bug per se — but the way n8n handles context across executions can be confusing, especially when $execution.mode is used for logic branching. The UI makes it look like the context is shared, but under the hood, it’s a separate execution without inherited metadata.

I hope that helps.

[JohnDoe]

As much as I was expecting that it is just a “feature” that is a little confusing to me it still does NOT explain why it displays “test” for starting the workflows directly (with form trigger and without subworkflow call)

Even with such workflow when you start it with “production URL” it displays wrong value, this must be a bug, isn’t it?

[King_Samuel_David]

Hi John,

When viewing your workflow within the n8n editor (specifically within the expression preview pane), expressions like $execution.mode default to pulling data from the live editor context, which typically returns "test" . This behavior occurs because the editor itself is always in test mode.

When invoking the workflow manually from within the editor, this is accurately considered a test execution, hence explicitly showing "test" in the preview pane.

However, when calling this workflow from another workflow or triggering it via the production URL (webhook, form submissions, schedules, or external API calls), the actual runtime environment takes effect. In these real runtime scenarios, $execution.mode correctly reflects the execution context, displaying "production" , as confirmed in your actual node output data.

Regarding your screenshot from the executions tab: Ideally, the executions history view should reflect "production" as the actual context used during execution. However, it seems the GUI incorrectly pulls the $execution.mode metadata from the live editor context (which is always in test mode), rather than from the execution data itself. Thus, it incorrectly displays "test" despite the execution being in "production" mode.

For additional details, you can refer to official documentation here:

• n8n Built-in Metadata - $execution.mode
• Manual, Partial, and Production Executions

Let me know if you have any further thoughts on this

Best regards,

Samuel

[Wouter_Nigrini]

You can always pin the data the sub-workflow would receive and then test from there by clicking the little play button on the node you want to start test execution from. This way you can test different starting points from the workflow you want to test.

In your case the workflow calls itself, so pin data on the “When Executed…” node, then click the play button on that node. Then click the play buttons on the next node and so on. Hope that makes sense?

Now when I just run it as normal I get “name: Peter Pan”, but when I click the play button on the No operation node, I see “name: Mary Jane”