Oracle Database node: Maximum call stack size exceeded when Select/Execute returns many rows

[kevinyelee]

n8n Oracle Node — Maximum call stack size exceeded (Issue Draft)

Summary

In the Oracle Database node (packages/nodes-base/nodes/Oracle/Sql), "Maximum call stack size exceeded" can occur when a Select or Execute SQL operation returns a large number of rows (on the order of tens of thousands, e.g. 10k–100k+). The root cause is the same pattern already fixed in other nodes (Microsoft SQL #8333/#8334, FTP #8657, MongoDB #8530, MySQL #10965): using Array.prototype.push.apply(array, largeArray) or array.push(...largeArray) to append many items at once. JavaScript engines limit the number of arguments to a function; when that limit is exceeded, the stack overflows.

Root cause (file and locations)

File: packages/nodes-base/nodes/Oracle/Sql/helpers/utils.ts
Function: configureQueryRunner (returned async function that runs queries and builds returnData)

1. Transaction branch

When stmtBatching === 'transaction', after executing each query the code does:

returnData.push.apply(returnData, executionData);
// or
returnData.push.apply(returnData, resultOutBinds);

Here executionData / resultOutBinds can be the full result set of a SELECT or Execute Query (e.g. 50k rows). Passing that many arguments to push via .apply() exceeds the engine’s limit and triggers the error.

2. Independently branch

When stmtBatching === 'independently', the same pattern appears:

returnData.push.apply(returnData, executionData);
returnData.push.apply(returnData, resultOutBinds);

Again, for a single item that runs one large SELECT, taskResults.rows is huge, so executionData is huge and push.apply blows the stack.

3. _getResponseForOutbinds (optional hardening)

Inside _getResponseForOutbinds:

if (executionData) {
  returnData.push(...executionData);
}

If constructExecutionMetaData ever returns a large array in this path, the spread form push(...executionData) can also cause stack overflow. Replacing this with a loop would make the node robust for any size.

Suggested fix

Avoid passing a large number of arguments to push. Append in a loop instead.

Replace returnData.push.apply(returnData, executionData) (and same for resultOutBinds)

Before:

returnData.push.apply(returnData, executionData);

After:

for (const item of executionData) {
  returnData.push(item);
}

Same for resultOutBinds:

for (const item of resultOutBinds) {
  returnData.push(item);
}

Apply this in both the transaction and independently branches (four replacements in total).

Optional: harden _getResponseForOutbinds

Before:

if (executionData) {
  returnData.push(...executionData);
}

After:

if (executionData) {
  for (const item of executionData) {
    returnData.push(item);
  }
}

This matches the approach used in the Microsoft SQL, FTP, MongoDB, and MySQL fixes and avoids stack overflow regardless of result set size.

Steps to reproduce

1. Add an Oracle Database node.
2. Configure credentials and choose Select (or Execute SQL with a query that returns many rows).
3. Set Return All (or a high limit) so the query returns e.g. 15,000+ rows.
4. Run the workflow.
   Observed: RangeError: Maximum call stack size exceeded (or similar).
   Expected: Rows returned without stack overflow.

Environment

• n8n version: (e.g. self-hosted latest from master or a specific version)
• Node version: (e.g. 18.x / 20.x)
• Oracle backend: any (issue is in JS array handling, not DB)

References

• Microsoft SQL fix: #8334 (same pattern, same fix)
• FTP fix: #8657
• MongoDB fix: #8530
• MySQL fix: #10965 / #11242

Thank you for maintaining the Oracle node; applying the same pattern as in the above PRs should resolve this issue.

[n8n-assistant]

Hey @kevinyelee,

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-7260".

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-7260

[kevinyelee]

Reproduction data

Scenario: Execute SQL returns ~5000 rows (paginated slice: WHERE rnum > 40000 with ROWNUM <= 45000, i.e. rows 40001–45000). This triggers "Maximum call stack size exceeded".

Input (query):

[
  {
    "querySql": "\nSELECT \n  sfmfuc.sfmfuc003 as machine_code_raw,\n  sfmfuc.sfmfuc021 as product_model,\n  sfmfuc.sfmfuc008 as production_speed,\n  sfmfuc.sfmfuc004 as dry_glue_lower,\n  sfmfuc.sfmfuc005 as dry_glue_upper,\n  sfmfuc.sfmfuc006 as width_lower,\n  sfmfuc.sfmfuc007 as width_upper,\n  imaa.imaa001 as material_code,\n  imaa.imaa132 as material_width,\n  sfmauc.sfmauc001 as product_model_from_sfmauc,\n  sfmauc.sfmauc008 as dry_glue_amount,\n  sfmguc.sfmguc001 as machine_product_model,\n  sfmguc.sfmguc003 as machine_code_from_sfmguc,\n  sfmfuc.sfmfucsite as factory_code\nFROM (\n  SELECT a.*, ROWNUM rnum FROM (\n    SELECT * FROM sfmfuc_t_v \n    WHERE sfmfucsite IN ('SHNAR', 'ALL') AND sfmfuc021 IS NOT NULL AND sfmfuc003 IS NOT NULL\n    ORDER BY sfmfuc021, sfmfuc003\n  ) a WHERE ROWNUM <= 45000\n) sfmfuc\nJOIN (\n  SELECT * FROM sfmauc_t_v \n  WHERE sfmaucsite IN ('SHNAR', 'ALL')\n) sfmauc ON sfmauc.sfmauc001 = sfmfuc.sfmfuc021\n  AND sfmauc.sfmauc008 >= sfmfuc.sfmfuc004\n  AND sfmauc.sfmauc008 <= sfmfuc.sfmfuc005\nJOIN (\n  SELECT imaa001, imaa132, imaa127 FROM imaa_t_v\n  WHERE imaa001 IS NOT NULL\n) imaa ON REGEXP_REPLACE(imaa.imaa127, '[一-龥]', '') = sfmauc.sfmauc001\n  AND imaa.imaa132 >= sfmfuc.sfmfuc006\n  AND imaa.imaa132 <= sfmfuc.sfmfuc007\nJOIN (\n  SELECT sfmguc001, sfmguc003 FROM sfmguc_t_v\n  WHERE sfmgucsite IN ('SHNAR', 'ALL')\n  AND sfmguc003 IS NOT NULL\n) sfmguc ON sfmguc.sfmguc001 = sfmauc.sfmauc001\nWHERE rnum > 40000\nORDER BY sfmfuc.sfmfuc021, sfmfuc.sfmfuc003\n"
  }
]

Output (error):

[
  {
    "message": "Maximum call stack size exceeded",
    "item": {
      "querySql": "\nSELECT \n  sfmfuc.sfmfuc003 as machine_code_raw,\n  sfmfuc.sfmfuc021 as product_model,\n  ...(same query as above)\n"
    },
    "error": {
      "level": "warning",
      "tags": {},
      "timestamp": 1773391775942,
      "context": { "itemIndex": 0 },
      "functionality": "regular",
      "name": "NodeOperationError",
      "node": {
        "parameters": {
          "resource": "database",
          "operation": "execute",
          "query": "{{ $json.querySql }}",
          "options": {}
        },
        "id": "0c108781-d1d3-4a2b-b9e0-963bc9fe57c3",
        "name": "Read Oracle Batch",
        "type": "n8n-nodes-base.oracleDatabase",
        "typeVersion": 1,
        "position": [-768, 240],
        "credentials": {
          "oracleDBApi": {
            "id": "jLiu7B6ZngoBYfJg",
            "name": "Oracle Database Credentials account"
          }
        },
        "onError": "continueRegularOutput"
      },
      "messages": []
    }
  }
]

Summary: Node "Read Oracle Batch" (Oracle Database, operation Execute SQL), single item with query = {{ $json.querySql }}. The SQL returns ~5000 rows (paginated slice rnum > 40000 with ROWNUM <= 45000). Execution fails with NodeOperationError and message "Maximum call stack size exceeded", consistent with the push.apply / large result set issue described in the issue.