UI Freezes while editing JS formula

Describe the problem/error/question

I have not been able to edit this workflow without the UI crashing. While I’m editing, the UI just freezes completely and never recovers. Whenever I type the string that triggers it - for example typing a ‘(’ after reverse - that same string always causes a freeze in the same place. I’ve tried downgrading from 1.21.0 to 1.18.1 and still have the same problem.

What is the error message (if any)?

See this video for the freeze behavior:

Please share your workflow

Note access keys removed but I can share in a private message if needed.

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 1.18.1 and 1.21.0
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): queue
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker / ECS.
  • Operating system: Alpine Linux

i have strange workaround to test. Try to use Set lower version. from 3.2 to 2

I noticed that with the change of version and moving Set node to a more complex version (new) I sometimes had a memory overflow (encountered in the first versions after switching to 1.x) or very much slowed down the editing of the value inside the node, if you enter js formulas text in real time.

The node version and values can also be changed in a local text editor by simply copy editing and pasting into the scenario. This helped me once too.

Sometimes it helps to just wait (by clicking continue button) because it takes time to render and calculate the value, because memory overflow. Then if everything is entered as it should be - leave it.

Happy to try that, @lightcom . How do I downgrade just the Set module? I’m self hosted so I can pull code from different n8n versions if that’s the trick.

Yeah, that’s exactly what it’s for. I posted above set node version 2. Your version in blueprint is 3.2
Copy and edited via notepad

“name”: “Extract PickedUp and LastEvent Time”,
“type”: “n8n-nodes-base.set”,
“typeVersion”: 2Change Here,
“position”: [

The typeVersion is responsible for the version of the node, and it is very convenient. I still sometimes use the first version of google sheets node this way. I’ve been using the same trick since I was a Make user, it’s a similar principle.

I hope this helps temporarily.

Hey @Lee_S, I think it happens because the value you are trying to access is too big to display it in the interface. Said that it should not freeze the browser anyway…

Have you tried adding a JS node one step before your “Set” and tried to run the javascript prior?

@lightcom That’s a really neat trick, thank you!

I just tried to find a list of available versions. Confusingly, when you look in the git repo (https://github.com/n8n-io/n8n/tree/release/1.21.1/packages/nodes-base/nodes/Set), set module V2 is for versions 3, 3.1, and 3.2; V1 is for versions 1 & 2. So I guess I’ll go with typeVersion 2, which is really V1.

@yukyo it seems to freeze when I type an open parenthesis for .reverse(. I’m not sure the problem is with the size of the result displayed below, although it could be. In my second example (around 1:12 in the Loom video), entering $json.Array.sort((x) => x.eventTimestamp) works just fine, but when I add “.reverse(” it hangs. The size of the result set should be the same.

I think the UI wants to autocomplete “.reverse(” by adding a close parenthesis, but then something goes wrong and it hangs. I think it’s smart enough to know that .sort has parameters so it doesn’t try to autocomplete with a close (, whereas reverse has no parameters. That’s pretty cool, actually.

@yukyo Just another note that you may be on to something with the freeze being related to the input content. When I edit the formula before any executions, everything seems to work fine. It’s only when there’s sample data that I seem to have this problem.

Yesterday I had a situation with memory overflow on one of the scripts (some kind of critical failure), on Google Chrome overflow of more than 4gb caused the tab to crash.

On Firefox (108.0.1) opening execution took a significant memory approaching 32 gigabytes (which is significantly higher than in Chrome), which allows to open high loaded scenaros.

limit - Firefox >4GB+ than Google Chrome

Of course it won’t solve the problem, but maybe it can work for us.

Hi folks, I’m sorry you’re having trouble with this. Perhaps our frontend specialist @mutdmour has an idea of what’s causing this and how to fix it?

I’m facing the same freezing while edit the code node, maybe there’s a bug.

For the moment I’m getting around this by using code modules instead of edit/set modules, because the code editor seems to be different and less sensitive.

But I’ve also seen that the editor REALLY slows down in any kind of module (not just edit/set) when the workflow is complicated or when there’s a lot of data from a previous flow. It makes it much more time consuming to develop anything because I have to slow my typing down so much.

This “UI slowness” is definitely a critical usability issue. I can’t imagine I’m the only one seeing it.

1 Like

same, freezeezed on a new edit node if used multiple javascript values as replace split calculations and so on (not memory death but stuck (page became unresponding). latest stable 1.22.4

I think it’s a problem of over-calculation. It feels like it recalculates the whole data array every time you edit one value, it recalculates everything.

Thank you everyone. Have created a follow up ticket to follow up on this.

made a copy of the node in 3.2 (same parameters as in v1)

  • Started the profiler
  • Entered the node
  • entered the number 1 in the value of the first parameter
  • stopped recording

all profiler records via link Transfer "profiler" is available for download
Profile-20240116T153914 new set node v3.2.json
Profile-20240116T153744 old set node v1.json

maybe helps