Error in js code node

Questions
1

Node execution failed

This can happen for various reasons. Please try executing the node again. If the problem persists, you can try the following:

  1. Reduce the number of items processed at a time, by batching them using a loop node
  2. Increase the memory available to the task runner with ‘N8N_RUNNERS_MAX_OLD_SPACE_SIZE’ environment variable.

Above error i get in the below code , please let me know need to change the code or something in the hosting time?It occure first time , my flow is on the production from 8 month.

const xlsx = require(‘xlsx’);
const binaryKey = Object.keys(items[0].binary)[0];
const buffer = await this.helpers.getBinaryDataBuffer(0, binaryKey);
const workbook = xlsx.read(buffer, { type: ‘buffer’ });

// Get visibility metadata
const visibility = workbook.Workbook?.Sheets?.map(sheet => sheet.Hidden) || ;

// Filter only visible sheets (Hidden !== 1 or 2)
const visibleSheets = workbook.SheetNames.filter((name, index) => {
return !visibility[index]; // false or 0 = visible
});

// Return only visible sheets
return visibleSheets.map(sheet => ({
json: { sheetName: sheet }
}));

3

Hi @NISHANT_GARG

Please share your workflow to provide better context.
What is the type of n8n setup?
Are you using docker?
Can you share the compose file?

5

I am freelancer.

I can’t share the workflow, Also i do not have the Docker file as it is hosted by the client on the Azure using the Docker.

For context purpose - I am using the mail to receive the attachments and then in the loop trying to get the name of the sheets from the Xl sheet.

At a time there is the single file to process for the code node.

Thanks.

image
image401×242 18.1 KB

6

@NISHANT_GARG you’re loading the full workbook just to read sheet names—that’s blowing runner memory on big files. Pass bookSheets: true so xlsx parses metadata only, skipping cell data.

{
 "parameters": {
 "jsCode": "const xlsx = require('xlsx');\nconst binaryKey = Object.keys(items[0].binary)[0];\nconst buffer = await this.helpers.getBinaryDataBuffer(0, binaryKey);\nconst wb = xlsx.read(buffer, { type: 'buffer', bookSheets: true, bookProps: true });\nconst vis = wb.Workbook?.Sheets || [];\nreturn wb.SheetNames.filter((n, i) => !vis[i]?.Hidden).map(sheetName => ({ json: { sheetName } }));"
 },
 "name": "Get Visible Sheets",
 "type": "n8n-nodes-base.code",
 "typeVersion": 2
}

Also bump N8N_RUNNERS_MAX_OLD_SPACE_SIZE=2048 on the Azure container—default 512MB crashes on big xlsx buffers.

7

good day @NISHANT_GARG

I would also add a few defensive checks before reading the workbook, because this may not be only a memory issue. Since the flow has been running for months and failed for the first time, I would check whether this specific email attachment is larger than usual, corrupted, password protected, or not really an XLSX file. So I would first confirm whether the latest attachment is unusual, add input validation, and only then decide whether the Azure Docker setup needs more memory.

8

Hey @NISHANT_GARG, great to see you’ve been running this in production for 8 months - that alone says you built the workflow well!

The suggestions above are all solid. I just want to add one more angle since this is a production flow: the fact that it worked for months and suddenly failed is a strong signal that something changed about the input file, not the code.

A few quick things to check before touching your environment config:

  1. Check the attachment size first - add a quick IF node before the Code node to verify the binary size is within expected range. Something like {{ $binary.data.fileSize > 5000000 }} to catch unusually large files and route them differently.

  2. Wrap the xlsx parsing in try/catch so instead of a hard failure you can log the error and notify yourself:

try {
  const workbook = xlsx.read(buffer, { type: 'buffer' });
  // ... rest of your code
} catch (e) {
  return [{ json: { error: e.message, fileName: binaryKey } }];
}
  1. If after checking the file everything looks normal, then yes bump N8N_RUNNERS_MAX_OLD_SPACE_SIZE to 2048 on your Azure container as @achamm mentioned.

Hope this helps narrow it down quickly!