Expressions silently resolve to null when Execute Workflow returns items with out-of-range pairedItem input index

[Marshall-Qiu]

Bug Description

When an Execute Workflow node returns items from a sub-workflow, the sub-workflow's internal pairedItem metadata can pass through to the parent unchanged. If the sub-workflow's final node was a multi-input node (e.g. Merge) and the item came through input index ≥ 1, the parent receives an item with pairedItem: { item: 0, input: 1 } — but the Execute Workflow node only has one input.

Any downstream expression that uses paired-item resolution across that node (e.g. $('Webhook').item.json.field) then silently resolves to null. No expression error, no failed node, no log line — the node runs "successfully" with an empty value, and the failure surfaces much later (in our case as a confusing 400 from an external API that received a parameter with no value).

The behavior is intermittent in real workflows because it depends on which input of the sub-workflow's final Merge produced the winning item on that particular run — which makes it very hard to debug from the outside.

Three separate issues stack up to produce the silent null (all verified on current master, 5c20436):

1. Sub-workflow pairedItem passthrough — packages/nodes-base/nodes/ExecuteWorkflow/ExecuteWorkflow/ExecuteWorkflow.node.ts (~L462–474): when getExecutionDataById returns no run data (e.g. sub-workflow has "save successful executions" disabled) or findPairedItemThroughWorkflowData returns undefined, the item keeps its sub-internal pairedItem verbatim, exporting an input index that is out of range in the parent context.

2. Paired-item resolver throws a raw TypeError instead of an ExpressionError — packages/workflow/src/workflow-data-proxy.ts, getPairedItem: candidates whose input exceeds sourceArray.length are dropped via return [] inside the flatMap, leaving results empty. Then:

   if (results.every((result) => !result.ok)) {
     throw results[0].error;   // results is [] → results[0] is undefined
   }

   [].every(...) is vacuously true, so this line throws TypeError: Cannot read properties of undefined (reading 'error') instead of one of the intended typed errors (verified by wrapping the expression in a try/catch inside the expression itself).

3. The expression engine swallows unknown errors — packages/workflow/src/expression.ts, renderExpression: the catch block rethrows only ExpressionError/ExpressionExtensionError/SyntaxError (plus a frontend-only TypeError case). A backend TypeError falls through and the function does return null, so the expression "succeeds" with null and the node keeps executing with an empty parameter value.

Any one of these being fixed would turn the silent wrong value into a visible, diagnosable error.

To Reproduce

Minimal setup — two workflows.

Sub-workflow (note: last node is a Merge fed only via input 2 / index 1; "save successful executions" set to Do not save so the pairedItem remap in Execute Workflow has no run data to work with):

{
  "name": "repro-sub",
  "nodes": [
    { "id": "n1", "name": "Start", "type": "n8n-nodes-base.executeWorkflowTrigger", "typeVersion": 1.1, "position": [0, 0], "parameters": { "inputSource": "passthrough" } },
    { "id": "n2", "name": "Merge", "type": "n8n-nodes-base.merge", "typeVersion": 3.2, "position": [220, 0], "parameters": {} }
  ],
  "connections": { "Start": { "main": [[ { "node": "Merge", "type": "main", "index": 1 } ]] } },
  "settings": { "executionOrder": "v1", "saveDataSuccessExecution": "none" }
}

Parent workflow (a Set node named Webhook stands in for a real webhook; the consumer node uses the paired-item expression):

{
  "name": "repro-parent",
  "nodes": [
    { "id": "p1", "name": "When clicking Test", "type": "n8n-nodes-base.manualTrigger", "typeVersion": 1, "position": [0, 0], "parameters": {} },
    { "id": "p2", "name": "Webhook", "type": "n8n-nodes-base.set", "typeVersion": 3.4, "position": [200, 0], "parameters": { "assignments": { "assignments": [ { "id": "a1", "name": "webhookUrl", "type": "string", "value": "https://example.com/webhook/abc" } ] }, "options": {} } },
    { "id": "p3", "name": "CallSub", "type": "n8n-nodes-base.executeWorkflow", "typeVersion": 1.2, "position": [420, 0], "parameters": { "source": "database", "workflowId": { "__rl": true, "value": "<repro-sub id>", "mode": "id" }, "options": {} } },
    { "id": "p4", "name": "Consumer", "type": "n8n-nodes-base.set", "typeVersion": 3.4, "position": [640, 0], "parameters": { "assignments": { "assignments": [ { "id": "b1", "name": "host", "type": "string", "value": "={{ $('Webhook').item.json.webhookUrl.includes('staging') ? 'https://staging.example.com' : 'https://prod.example.com' }}" } ] }, "options": {} } }
  ],
  "connections": {
    "When clicking Test": { "main": [[ { "node": "Webhook", "type": "main", "index": 0 } ]] },
    "Webhook": { "main": [[ { "node": "CallSub", "type": "main", "index": 0 } ]] },
    "CallSub": { "main": [[ { "node": "Consumer", "type": "main", "index": 0 } ]] }
  },
  "settings": { "executionOrder": "v1" }
}

1. Import both workflows, point CallSub at the sub-workflow.
2. Execute the parent.
3. Inspect the output:
   • CallSub output item: pairedItem: { "item": 0, "input": 1 }
   • Consumer output: { "host": null } — execution status: success, no error anywhere.

Control: change the sub-workflow's single connection from Merge input 1 to input 0 and run again — Consumer now outputs { "host": "https://prod.example.com" }. The one-line change toggles the bug.

Expected behavior

Either the paired-item chain resolves correctly (ideally Execute Workflow remaps or strips sub-internal pairedItem so parent-side metadata is always valid), or — at minimum — the expression fails loudly with a proper ExpressionError ("no path back to node …"), failing the node so the wrong value never propagates. An expression should never silently produce null because of internal metadata corruption.

Environment

• n8n Version: reproduced on master @ 5c20436 (2.30.0 dev); first observed on a self-hosted 1.x deployment in queue mode
• Node.js Version: 24.7.0
• Database: SQLite (repro), PostgreSQL (original occurrence)
• Execution mode: regular (repro), queue (original occurrence)
• Operating System: macOS 15 (repro), Linux/Kubernetes (original occurrence)

[n8n-assistant]

Hey @Marshall-Qiu,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-9192".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-9192

[Marshall-Qiu]

Additional finding from tracing the original production occurrence: there is a second path that leaks a sub-internal pairedItem to the parent, independent of the "no run data → keep verbatim" path in the repro above.

When Execute Workflow does have the sub-execution's run data, it calls findPairedItemThroughWorkflowData (packages/nodes-base/utils/workflow-backtracking.ts). That helper is documented as linear-only, and it has two compounding problems:

1. previousTaskData follows only source[0]. If the lineage passes through a Merge node that received data only on input ≥ 1 (its source[0] is null because the other branch didn't run), the walk dead-ends at the Merge.
2. On dead-end, the while loop simply exits and the function returns the intermediate pairedItem it last read — e.g. the Merge's {item: 0, input: 1} — instead of undefined. This violates the contract stated in the file's own header comment ("If we cannot backtrack correctly, we return undefined to fallback"). Execute Workflow then assigns that sub-internal value as the parent-side pairedItem.

Net effect is identical to the repro: the parent holds pairedItem: {item: 0, input: 1} on a single-input node, and any downstream $('Node').item expression silently resolves to null via issues 2 and 3 in the original report.

This second path is what actually happened in our production case: a sub-workflow with two mutually exclusive branches (a Switch routes to branch A → Merge input 0, or branch B → Merge input 1, mode: append). Runs through branch A work; runs through branch B dead-end the backtracker at the Merge and poison the parent — which is why the failure appears random from the outside.

Suggested fix for this path: in findPairedItemThroughWorkflowData, pick the source entry matching the current pairedItem.input (falling back across non-null sources), and return undefined whenever the walk terminates before reaching the first task data.

[Shinu-Cherian]

Hi @Joffcom and @Marshall-Qiu, I've been looking into this issue and I have a clear plan on how we can fix this. As Marshall pointed out, the silent nulls are caused by a combination of unhandled empty arrays and incomplete backtracking.

1. Root Cause / Analysis

There are two main areas causing this:

• In packages/workflow/src/workflow-data-proxy.ts -> getPairedItem: When inputIndex >= sourceArray.length, it returns an empty array. The condition if (results.every((result) => !result.ok)) is vacuously true for empty arrays, causing it to throw results[0].error which triggers a raw TypeError (since results[0] is undefined).
• In packages/nodes-base/utils/workflow-backtracking.ts -> previousTaskData: It hardcodes the traversal to source?.[0]. If a sub-workflow path passes through a Merge node that received data on input >= 1, the traversal hits a dead-end and incorrectly returns the intermediate pairedItem instead of undefined.

2. Proposed Solution

• In workflow-data-proxy.ts: Add a safety check in getPairedItem to throw a proper ExpressionError (or createMissingPairedItemError) if the results array is empty, rather than trying to access results[0].error.
• In workflow-backtracking.ts: Update previousTaskData and the loop in findPairedItemThroughWorkflowData to pick the source entry matching the current pairedItem.input (falling back to the first non-null source). If the walk terminates early, ensure it strictly returns undefined.

3. Impact

This will ensure that out-of-range paired item resolutions throw a visible, diagnosable ExpressionError instead of silently swallowing the unknown TypeError and resolving to null. It will also fix the backtracking logic so sub-workflows with branching (like Switch -> Merge) don't poison the parent workflow's paired items.

If you like this approach, I am highly interested in working on this fix and can raise a PR right away. Please let me know!

[Joffcom]

@Shinu-Cherian I would let the team handle this as there is a good chance something might break and AI tooling might not have the full context.

[mrduck30]

Thanks for the detailed investigation. The silent null behavior seems much harder to diagnose than an explicit error because the workflow appears to succeed until a downstream node fails. I haven't reproduced this myself yet, but I'll keep an eye out for similar behavior in my workflows. If I manage to reproduce it, I'll add my findings here to help confirm the issue.