Describe the problem/error/question
This is a self-hosted version. I am having two issues, one of which I found a workaround for but wanted to make others aware.
- The code node since moving to 2.0+ doesn’t like to perform http requests, I require axios and it used to work fine in the older versions with try, catch. Now, any error crashes the code node with a ‘N8N_RUNNERS_MAX_OLD_SPACE_SIZE’ error, at least for all of my requests to Freshdesk I now need to include validateStatus: () => true // NEVER throw on any HTTP status in the request to ensure it doesn’t crash and instead provides me the error to handle it.
- The code nodes code screen doesn’t fit the screen, it puts a scroll bar within a scroll bar, I have to scroll all the way to the bottom to see the find option or pop out the code into focus. Example image attached.
Information on your n8n setup
- n8n version: 2.15
- Database (default: SQLite): Postgres
- n8n EXECUTIONS_PROCESS setting (default: own, main): default
- Running n8n via (Docker, npm, n8n cloud, desktop app): docker
- Operating system: Windows 11
1 Like
I ran into something very similar on a self hosted setup after moving to the newer 2.x runners.
The behavior you are seeing with axios is related to how the newer runner process handles thrown errors inside the code node. When axios throws on a non 2xx response it bubbles up as an unhandled error in the runner and the process can terminate instead of letting you deal with the response in code. That is why using validateStatus: () => true works because axios stops throwing and simply returns the response object for you to inspect.
Another approach that worked better for me with APIs like Freshdesk was to avoid letting the library throw at all and handle the response state manually. Either by using validateStatus as you mentioned or by wrapping the request logic so that every response is normalized before the code node tries to process it. Once the response is always returned instead of thrown the runner behaves normally and the memory error stops appearing.
There is also a small pattern that helps when calling APIs repeatedly from the code node so that failures never terminate the runner and you can still branch logic based on status codes or error bodies. After switching to that pattern the node stopped crashing even with failing API responses.
The double scrollbar in the editor is a UI quirk that shows up on some screen sizes in the newer UI. Popping the editor into focus or reducing the panel width tends to remove the nested scroll container. It looks like a layout issue rather than anything related to the workflow itself.
I ended up settling on a small structure for code node API calls that keeps the runner stable even when the API throws rate limits or 4xx and 5xx responses. It made a big difference for Freshdesk style endpoints where errors are common but expected.
yeah Marvel1 covered most of it. the try-catch on top of validateStatus is basically how we ended up handling it too, thats what keeps the runner from seeing unhandled rejections on 5xx responses. for the scrollbar, hitting the expand button on the editor tends to fix it, or just resize the panel.
1 Like
hi @Ben_Crider
At this point, I think the most useful next step would be to isolate whether this is specific to axios in the Code node runner or a broader runner issue with thrown HTTP errors in general. A minimal repro would help a lot here, especially if the same failing call behaves differently in the HTTP Request node.
For the UI part, that also sounds consistent with an editor layout issue rather than anything execution-related, so it probably deserves to be tracked separately from the runner behavior.
