Doubled strings

n8n version: 1.31.2
I have a Gmail trigger and one of the fields are

date”: “2024-03-19T09:42:11.000Z”,

I set it with {{ $ }}


Result is usually like
“longDate”: “2024-03-19T07:35:34.000Z”,

But in some real executions it doubles up to
“longDate”: ““2024-03-19T09:42:09.000Z””,


If I copy the execution input to test with, I get it fine again

What’s wrong?

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

hello @bally
Are you using the syntax like this somewhere?

"{{ JSON.stringify($}}"

That usually happens because the stringify method adds double quotes around the payload. So if you have them added manually, then it would be doubled

Or if you have set variables like this

No it’s only set where you see above

{{ $ }}

so I don’t know why it varies between different executions.

Does the doubling happen only after the Edit fields node?

Yes this is where I set the field name
does not happen in test mode and does not always happen in production mode

I’m gonna put the dates in the code right away instead of using the set node

I have seen this resported before but have not been able to reproduce it, Can you share a workflow that reproduces the issue?

It’s the 1st thing after a gmail trigger.
It’s fine now with a code block instead
maybe I should use code blocks instead of the set field

Code blocks can cause issues with memory if not needed, It would be interesting to see if you get the same issue on 1.34.1 which was released today.

In terms of nodes is it better to have fewer or have more smaller individual nodes
for example the set fields I tend to use just to clean up and remove fields I don’t need
have never actually thought about the memory or other processing it causes

this one I’m using the dates because it seems to break in every other way I do it eventually

technically I could absorb the set field into the code block as well but I prefer having more things in the UI

and then in this one I’m doing a migration so

I find that a lot of times I’m using the set field too get out things I need and then emerge to bring in the things I need from the stages before

I’m not sure but this is a good way to deal with the data

There isn’t really a right or wrong way to do things as long as it achieves the goal that is the first step from there it is about cutting down and removing what might not be needed.

I often use the Edit Fields node to keep only what I need and as you have noticed sometimes a merge is the best way to get data joined back together. The problem with the code node is when it runs it has to create a new sandbox which consumes a bit of memory but it soon adds up if you use multiple code nodes.

Breaking up your workflow into subworkflows is always a good idea as once that workflow has finished the memory is cleared and is available for the main workflow again which if dealing with a lot of data can be very handy.

The doubled strings may now be fixed so it could be worth an update to double check.


I’ll have a try again.
So better having eg
{{ DateTime.fromMillis($‘yyyyMMdd’) }}

in Multiple fields in a set
vs a clean code and a variable and then using the result in several times?

I did this in a code block because I thought it would be easier to read but I guess in theory I could throw it in an if block right at the start

Then no code block at all

In another workflow I have

// Set dates
let dateField = DateTime.fromFormat($, "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
let emailDate = dateField.toFormat("yyyyMMdd");
let year = emailDate.substring(0, 4);
let timestamp = dateField.toMillis();

return { emailDate, timestamp, year };

To stick it in a set field would be very difficult.