I think I have a bug with the HTTP node

Hello everyone,

I have already opened a page on this subject, I have not found an answer/solution.

In my workflow I use a URL that returns a .json file. Every hour I compare it to the previous hour.

And sometimes the node returns an error. A 404 error that I can’t (most of the time) reproduce on a completely different n8n instance (either the one installed as a fat client on my Mac or the one at my work, self-hosted). The workflow is exactly the same. This surprises me a lot because usually shortly after the error I try to call the same URL on another instance: it works fine.

I run my workflows on the n8n cloud I bought (version 0.158.0) and my fat client runs with version 0.147.1.

Following a previous post, I was advised to delay the URL call by an hour, thinking that would fix the problem: not always.

Here is a piece of my workflow (which is more than enough to explain the situation):

Do you have any idea why I’m getting this kind of error when on a very different instance I have a 200 code? Even with the retry option in the HTTP node I have the same problem.

Thanks in advance

1 Like

Hi @arthurcorre

What is the allowed time limit in an hour?

I think this might either be due to the size of JSON data you’re receiving or requesting the JSON within the time limit.

Hello mcnaveen,

I don’t think I have a limit of hits per hour: I’ve sent nice loads to this URL, I’ve never had a problem. n8n checks each URL 2x per day (updated every hour), I’ve never had a message that I’ve reached a certain limit. Twitter does not give any information about this base.

I don’t think it’s due to the size of the file received, because depending on the hours, the file size changes very little, and I can display it on other n8n instances.

I think it’s something else entirely. For example a special character misinterpreted?

That looks like either the data is all wonky that is coming back or it is encrypted, is there a proxy in use anywhere doing content inspection?

Is there a more detailed error message further down the page?


No, no proxy is used.

Here is an extract of the error code obtained:

{"status":"rejected","reason":{"message":"404 - \"\\u001f�\\b\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000�kw�8�(�[��y��\\u001a���o\\\\\\u0013:\\\\21\\u001d��3ky\\t,@��x|I�>���#�@��U�\\u0002�@2�3\\u0019P\\u0015*WY�R�.����_S�Z#2w\\u0007h�����[email protected]�^����\\u0015\\tWVQ+\\u0016����\\u0002��\\u0000�\\u0019FA��ԛb7�}�\\u0004�\\u0001�����0�\\\"\\b��������o4��O�JV��3�����w0s������4R���ڝ3\\n~�����\\u0011Ya�y����Q�zU+��\\u001a��aa�\\u0016���Z�R�q���}�q�iZ��\\u0011'W�^�IfG�\\u0019Lvy�"name":"Error","stack":"Error: Request failed with status code 404\n    at createError (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/createError.js:16:15)\n    at settle (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:17:12)\n    at IncomingMessage.handleStreamEnd (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:269:11)\n    at IncomingMessage.emit (events.js:327:22)\n    at IncomingMessage.EventEmitter.emit (domain.js:467:12)\n    at endReadableNT (internal/streams/readable.js:1327:12)\n    at processTicksAndRejections (internal/process/task_queues.js:80:21)"}}

And a screenshot of what I get from n8n:

That is not as helpful as I was expecting it to be, So it looks like the Twitter service is throwing the rejected status. I am not sure why the message is garbage though that would normally tell us what it is unhappy with.

What I have done for now is set up the same workflow to run every hour here to see if I am able to reproduce the same issue, At a guess though I would say that twitter is possibly doing some rate limiting on your IP, Do you call that same URL from other workflows?

As a possible solution if you go to the settings for your HTTP Request node there is a retry on fail, If you set that to say max tries 5 and time to 30000 does that show any decrease in the amount of errors seen?

Does it often happen at the same time of day as well?

No I don’t call these URLs on other workflows, except on very different instances of n8n to try to reproduce the problem.

Each URL (24 are generated per day) is called twice a day to compare them with the current hour with the previous hour.

As mentioned above, I have used the retry parameter on failure, it never solved the problem. The 30s delay is far too short.

And finally, no, it doesn’t happen often at the same time of day, it’s very random… I think it’s due to special characters (very very special with Japanese/Chinese characters, I’m not able to say what here) that are misinterpreted sometimes?

Here is the start of my workflow set up so that it runs every new hour with the URL settings updated automatically: