n8n - 💡(How to fix) Fix [Bug] multipleValues fixedCollection iterates string characters when parameter value is an expression [1 comments, 2 participants]

Describe the bug

When a node parameter is declared as a fixedCollection with typeOptions: { multipleValues: true }, and the user sets that parameter via an expression (e.g. ={{ $json.items }}) instead of typing items literally into the UI's "Add Item" flow, NodeHelpers.getNodeParameters iterates the expression string's characters instead of the resolved array, producing N schema-default items where N is the string's character length.

The result is that nodes receive a phantom array of default-filled items, transparent to the node author. For an 18-character expression the node sees 18 default items instead of the 2-or-N real items the user expected.

To Reproduce

Minimal reproduction in any community node:

1. Define a parameter:

   {
     displayName: 'Items',
     name: 'items',
     type: 'fixedCollection',
     typeOptions: { multipleValues: true },
     default: {},
     options: [
       {
         name: 'itemValues',
         displayName: 'Item',
         values: [
           { displayName: 'Foo', name: 'foo', type: 'string', default: 'default-foo' },
         ],
       },
     ],
   }

1. In a workflow, place a Set node producing { items: [{ foo: 'a' }, { foo: 'b' }] }.

2. Wire its output to your custom node, and set items.itemValues to the expression ={{ $json.items }}.

3. Inspect the parameter value the node receives via getNodeParameter('items.itemValues', i) or the resolved request body if using declarative routing.

Expected: node receives [{ foo: 'a' }, { foo: 'b' }].

Actual: node receives 18 elements, each { foo: 'default-foo' }. (18 = '={{ $json.items }}'.length)

Root cause

NodeHelpers.getNodeParameters in packages/workflow/src/NodeHelpers.ts:723-770 (master at time of filing) loops over the parameter value with for (const nodeValue of propertyValues[itemName]). When propertyValues[itemName] is a string (i.e. an unresolved expression that hasn't been evaluated to its array value yet), the for-of iterates the string's characters. Each character is then treated as a fixedCollection row, recursively resolved through getNodeParameters, and emitted with schema defaults.

By the time a node's preSend hook or operation handler runs, node.parameters.<param>.<itemKey> has already been mutated to that defaults-array. The original expression string is unrecoverable from inside the node.

Impact

Any community or built-in node that exposes a multipleValues: true fixedCollection and intends to support dynamic-array input via expression is silently broken. The bug is invisible to the node author — request payloads are well-formed JSON with the right shape, just with N×default-items where N depends on the expression string length. Downstream APIs see a payload with too many items, or with all-default values, depending on what the node does with them.

Workaround

In [email protected], the consignment-shape operations (adrLqCheck, adrExemptionConsignment, consignment) added an itemsSource toggle parameter (default list) and a paired itemsJson (multi-line string) shown when itemsSource === 'json'. String parameters resolve expressions cleanly because they don't go through the broken fixedCollection-iteration path. Reference implementation: https://github.com/SoapyRED/n8n-nodes-freightutils/blob/v0.3.1/nodes/FreightUtils/FreightUtils.node.ts

Suggested fix direction (non-binding)

In the for-of at the iteration site, short-circuit when propertyValues[itemName] is a string. Either: (a) treat it as a single fixedCollection row needing further resolution upstream, or (b) defer to expression evaluation before structural iteration.

Environment

• n8n version tested: 2.18.5
• Affected: any node defining multipleValues: true fixedCollection accepting expression input
• Caught: 2026-05-01 in [email protected] consignment operations