Estou tentando descobrir por que um nó Information Extractor está fazendo 10+ chamadas a um LLM em uma única execução para uma única entrada - o problema é que está usando 10x o número de tokens necessário.
Estou usando um nó Information Extractor com Google Gemini 2.5 Flash. Estou usando um prompt bem grande e passando muito texto como conteúdo para analisar (25K+ tokens de prompt e conteúdo). O nó Information Extractor está configurado com um esquema JSON.
99%+ do tempo isso funciona perfeitamente. Hoje, tenho recebido mensagens de erro 524 como pop-ups na interface, e o nó Extractor está chamando o subnó Gemini 10+ vezes, aumentando a contagem total de tokens de 35K para mais de 500K.
Tenho as retentativas desabilitadas e continuar em erro, saída para uma interface de erro. Por que o nó extractor está enviando meu prompt e conteúdo para o modo LLM mais de uma vez? Como eu impedir esse comportamento indesejável?
Qual é a mensagem de erro (se houver)? Problema com retry
A solicitação falhou com o código de status 524
Por favor, compartilhe seu fluxo de trabalho
(Selecione os nós em sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)
@am4c130d esse 524 é um gateway timeout, o gemini simplesmente não respondeu a tempo hoje, e as 10+ chamadas são retentativas disparadas abaixo da retentativa no nível do node que você desativou, elas estão na camada do modelo. você pode verificar as opções no seu subnó Gemini Chat Model, qual é o máximo de retentativas definido lá?
No Information Extractor - retries estão desativados.
No nó gemini chat as únicas opções que tenho são: max tokens, sampling temperature, Top K, Top P, Safety Settings. Na aba de configurações há apenas uma opção de Notes.
@am4c130d é isso aí, o n8n não expõe o maxRetries do modelo então você não consegue limitar isso do nó, são retentativas internas do langchain disparando no timeout. o controle que você realmente tem é o 524 em si, é um gateway timeout que ativa quando uma chamada demora muito (uns 100s), e sua requisição de 25k tokens é lenta o suficiente pra bater nele enquanto o gemini tá lagado hoje. se conseguir, divide o conteúdo em passes menores pra cada chamada terminar bem antes disso, sem timeout não tem cascata de retry e não queima 10x. se realmente precisa dos 25k completos de uma vez, a outra opção é chamar o gemini através de um nó HTTP Request onde você controla timeout e retries você mesmo, aí faz o parse do json depois.
O 524 dispara uma cascata de retry em nível LangChain - essa é a causa raiz que achamm descreveu. Um corretivo adicional específico para n8n auto-hospedado: defina a variável de ambiente N8N_DEFAULT_HTTP_TIMEOUT para um valor maior (o padrão é 300000ms / 5 min). Se seu reverse proxy ou CDN tiver um timeout menor do que o tempo que sua chamada Gemini leva, o 524 é disparado antes de n8n conseguir completar, acionando retries antes da primeira chamada ter realmente falhado. Também vale a pena verificar: se você está usando Cloudflare, seu timeout de gateway padrão é 100 segundos, o que pode afetar chamadas Gemini 2.5 Flash com 25K tokens em dias de muito uso.
Obrigado - estou usando n8n cloud - então o n8n escolhe o proxy etc. Além de auto-hospedar, em que caso eu usaria um modelo local, vou seguir a solução do @achamm.