I am trying to solve why an Information Extractor node is making 10+ calls to an LLM in a single execution for a single input - the issue is it is using 10x the number of tokens needed.
I am using an Information Extractor node with Google Gemini 2.5 Flash. I am using a fairly large prompt and passing in a lot of text as content to analyze (25K+ tokens worth of prompt and content). The Information Extractor node is configured with a JSON schema.
99%+ of the time this works perfectly. Today, I’ve been receiving 524 error messages as pop ups in the UI, and the Extractor node is calling the Gemini subnode 10+ times, taking total token counts from 35K to over 500K.
I have retries disabled, and continue on error, output to an error interface. Why is the extractor node sending my prompt and content to the LLM mode than once? How do I prevent this undesirable behavior?
What is the error message (if any)? Problem with retry
Request failed with status code 524
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
@am4c130d that 524 is a gateway timeout, gemini just didnt respond in time today, and the 10+ calls are retries firing below the node-level retry you turned off, theyre at the model layer. can you check the options on your Gemini Chat Model subnode, whats the max retries set to there?
On the Information Extractor - retries are disabled.
On the gemini chat node the only options I have are: max tokens, sampling temperature, Top K, Top P, Safety Settings. Under the settings tab there’s only a Notes option.
@am4c130d yeah thats the catch, n8n doesnt expose the model’s maxRetries so you cant cap those from the node, theyre langchains internal retries firing on the timeout. the lever you actually have is the 524 itself, its a gateway timeout that trips when a call runs too long (around 100s), and your 25k-token request is slow enough to hit it while gemini’s laggy today. if you can, split the content into smaller passes so each call finishes well under that, no timeout means no retry cascade and no 10x burn. if it really needs the full 25k in one shot, the other route is calling gemini through an HTTP Request node where you control timeout and retries yourself, then parse the json after.
The 524 triggers a LangChain-level retry cascade - that’s the root cause achamm described. One additional fix specific to self-hosted n8n: set the N8N_DEFAULT_HTTP_TIMEOUT env variable to a higher value (default is 300000ms / 5 min). If your reverse proxy or CDN has a shorter timeout than your Gemini call takes, the 524 fires before n8n can complete, triggering retries before the first call has actually failed. Also worth checking: if you’re using Cloudflare, its default gateway timeout is 100 seconds which can hit 25K-token Gemini 2.5 Flash calls on busy days.