Estou usando n8n Cloud Starter, versão 2.17.5.
Um workflow que processa ~120–400 itens através de Loop Over Items e HTTP Requests recebe “connection lost / offline” e a execução é interrompida.
Os dados de execução são não confiáveis ou não são salvos corretamente.
Isso acontece mesmo após reduzir o payload e usar Data Tables.
Vocês podem confirmar se esse é um problema de recurso/timeout na Cloud e se meu plano pode suportar essa carga de trabalho?
Oi @kourG, bem-vindo!
Eu diria que esse número pode ser uma limitação do seu plano cloud starter se o seu workflow não estiver otimizado, embora 120-400 ainda seja bastante para acesso de compute do plano starter:
Aqui está algumas orientações que você pode considerar para otimizar esse fluxo:
Atualizar seu plano também pode resolver isso, mas depende do seu caso de uso; se crescer, você pode precisar ir ainda mais alto.
No Cloud Starter, 120 a 400 itens através de Loop Over Items mais HTTP Requests atingindo “connection lost” geralmente significa que a execução está excedendo o limite de memória ou tempo do plano, e não sua internet, especialmente se cada item carrega um payload considerável, porque o n8n mantém os dados de execução na memória durante a execução.
Algumas coisas que ajudam. Reduza o que cada item carrega antes do loop, descarte campos que você não precisa para que o payload em memória permaneça pequeno, o loop mantém tudo. Processe em sub-lotes menores e escreva os resultados conforme avança (em uma Data Table ou armazenamento externo) em vez de acumular tudo em uma única execução, para que uma falha no meio do caminho não perca toda a execução. E considere dividir o trabalho: um workflow que coloca os itens na fila, um segundo acionado por lote, para que nenhuma execução única tenha que manter o estado de 400 itens.
A parte “dados de execução não confiáveis ou não salvos” é o risco real para você, porque uma execução que falha no meio de um loop frequentemente já fez metade das gravações HTTP, e você não consegue saber quais vieram da execução quebrada. Torne as gravações idempotentes e rastreie quais itens foram concluídos em uma tabela externa, para que uma re-execução pule os já concluídos em vez de duplicá-los. Está falhando em uma contagem consistente de itens ou aleatoriamente? Consistente aponta para o teto de memória.
Já tentei reduzir o tamanho da carga útil e armazenar dados intermediários em Tabelas de Dados. Porém, quando o problema de “conexão perdida / offline” ocorre, nenhum dado parece permanecer na tabela, como se a execução nunca tivesse sido concluída ou os resultados intermediários nunca tivessem sido salvos.
Por isso, estou tentando entender se o problema está relacionado a um limite de recursos do Cloud Starter ou a um tempo limite de execução.
Com relação à sugestão de usar lotes, se entendi corretamente, você está recomendando que eu divida os 120–400 itens em grupos menores e os processe incrementalmente em vez de em uma única execução grande. Também estou considerando se seria possível carregar um novo lote após o término do processamento do lote atual no loop, para que o fluxo de trabalho possa continuar em partes menores. Vou experimentar essa abordagem e ver se melhora a estabilidade.
Além disso, estou usando o n8n Cloud Starter e não tenho controle direto sobre a atualização da versão do n8n, pois a versão é gerenciada pelo n8n Cloud. Você poderia confirmar se a versão 2.23.4 já está disponível na Cloud, ou se alguma ação é necessária por parte da equipe do n8n?
Sim, mas faça cada lote sua própria execução. Um Loop Over Items que carrega o próximo lote dentro da mesma execução ainda compartilha um envelope único de timeout/memória, então quando essa execução é interrompida o checkpoint pode desaparecer com ela.
Use uma execução para reivindicar um pequeno lote, escreva cada resultado/status do item antes de passar para o próximo item, depois deixe um Schedule ou Execute Workflow iniciar o próximo lote a partir das linhas ainda marcadas como pendentes. Para o sintoma da Data Table, publique onde o nó de escrita fica: antes da HTTP Request, depois de cada item, ou apenas depois que todo o loop termina?