Hi all, always awkward when your first post is asking a question
Is there any problem with long strings in JSON objects?
I’m using an edit fields node to format a JSON object that will be used in a HTTP request in the following node but I always get the error listed in the topic title despite the output parsing as valid JSON (all standards) in linters.
the node is listed below (hopefully)
if the {{ $json.data.quote()}} is replaced with a string the node works. When it has the output of the previous node (just a really long string but escaped because it contains " marks) it doesn’t work despite the output still parsing as valid outside of n8n.
Ensure to copy your n8n workflow and paste it in the code block, that is in between the pairs of triple backticks, which also could be achieved by clicking </> (preformatted text) in the editor and pasting in your workflow.
```
<your workflow>
```
That implies to any JSON output you would like to share with us.
Make sure that you have removed any sensitive information from your workflow and include dummy or pinned data with it!
It depends on what kind of data type/structure the expression $json.data.quote() returns. You might want to try transforming the whole JSON into an expression. That is, try out this
$json.data.quote() is just a really long string. It shouldn’t matter unless quote() can return something that isn’t a string.
Interestingly I think this is a bug in the output window.
In the first version n8n said the JSON was wrong but the output was valid and this way around the output window says it’s valid but the output doesn’t validate having extra quote marks around the long quoted string but does pass good data to the next node.
Thanks for your help. I’ll see if I can create a minimal example and report it as a potential bug.
The string doesn’t contain either. n8n thinks it’s not valid but cutting and pasting the result shows it passes RFC8259, RFC7159, RFC4627 and EMCA-404.
I’m a bit short on spoons tonight after a tough week returning to work after a few days off with the flu. If I can find the time I’ll try and reproduce with a minimal workflow to show that n8n suggests valid JSON isn’t correct and invalid JSON is correct. If I can find that then if it is an issue it should be easy to track down.