Gestió d'errors a n8n: reintents, Error Trigger i cua de morts

Aquesta és una de les tres guies del clúster d’automatització amb n8n. El tronc explica el model mental; aquí anem al que decideix si un flux es pot deixar sol: què passa quan alguna cosa falla.

I fallarà. Una API caurà, un límit de ritme et tallarà, una fila arribarà amb un camp buit. La pregunta no és si, sinó què fa el flux quan passa. Per defecte, un flux d’n8n que peta s’atura i calla. Si ningú ho mira, l’error viu fins que algú pregunta per l’informe que no ha arribat —normalment el client.

Tres capes, de la més fina a la més gruixuda

La gestió d’errors a n8n té tres nivells, i es fan servir junts:

1. Reintents per node — per als errors passatgers d’un pas concret.
2. La sortida d’error d’un node — per continuar el flux tot i que un pas falli.
3. El workflow d’error — la xarxa que recull tot el que se salta les dues anteriors i avisa.

1. Reintents per node: Retry On Fail

Cada node té, a la pestanya Settings, l’opció Retry On Fail. Quan l’actives, apareixen dos paràmetres:

• Max Tries — quantes vegades ho torna a provar. 2 o 3 és el rang normal.
• Wait Between Tries (ms) — quant espera entre intents.

La regla d’or és posar espera. Reintentar a l’instant contra una API que està saturada només hi afegeix càrrega. I si l’error és per límit de ritme, l’espera ha de ser més llarga que la finestra del límit: si l’API accepta una crida per segon, posa 1000 ms com a mínim.

Però el reintent per node té un límit conceptual que s’ha d’entendre: reintenta el mateix, igual. Serveix per a un 503 o un tall de xarxa passatger. No serveix per a un 400 (la petició és dolenta i ho serà les tres vegades), ni per a un 401 (les credencials no milloren esperant), ni per a un 404. Reintentar-los és gastar temps i, amb un límit de ritme pel mig, gastar quota.

Activa Retry On Fail només als nodes que parlen amb l’exterior —HTTP Request, nodes de base de dades, APIs— i deixa’l apagat als nodes de transformació, que no fallen per motius passatgers.

2. La sortida d’error: continuar tot i el fracàs

Quan un node falla i has esgotat els reintents, per defecte el flux s’atura sencer. Sovint no és el que vols: si processes 200 comandes i una porta un NIF invàlid, no vols que les altres 199 es quedin sense fer.

A Settings de cada node hi ha On Error amb tres opcions:

• Stop Workflow (per defecte) — s’atura tot.
• Continue — segueix, passant l’error com a dada.
• Continue (using error output) — apareix una segona sortida al node, de color vermell, per on surten només els items que han fallat.

Aquesta tercera és la bona per al processament per lots. Els items que van bé segueixen per la sortida normal; els que fallen surten per la vermella cap a una branca que els apunta i els aparta, sense tombar la resta.

                    ┌─ èxit ──────→ crear la comanda
  HTTP Request ─────┤
   (error output)   └─ error ─────→ apuntar a "pendents de revisar"

3. El workflow d’error: la xarxa de sota

Els reintents i les sortides d’error tapen el que preveus. El workflow d’error recull el que no: una excepció que no havies contemplat, un node que peta a mitja nit, un flux sencer que cau.

Es munta en dos passos:

Un flux nou amb el node Error Trigger com a primer node. Anomena’l, per exemple, Gestor d'errors. Aquest node rep, quan un altre flux falla, tots els detalls: quin flux, quin node, quin missatge, en quina execució.

// Dins del gestor d'errors, un node Code que munta l'avís
const err = $json;
return [{ json: {
  flux: err.workflow?.name,
  node: err.execution?.lastNodeExecuted,
  missatge: err.execution?.error?.message,
  quan: err.execution?.startedAt,
  enllac: err.execution?.url,   // porta directe a l'execució que ha fallat
} }];

Després envia això on el vulguis veure: un correu, un Slack, una fila a una taula.

Assignar-lo als fluxos que vols vigilar. A cada flux: Options → Settings → Error workflow, i tries el Gestor d'errors. A partir d’aquí, qualsevol fallada d’aquell flux engega el gestor.

Un avís que estalvia una tarda de confusió: el workflow d’error no es dispara en execucions manuals. Només salta quan un flux automàtic (per horari o webhook) falla de veritat. Provar-lo clicant «executar» no fa res; l’has de provar deixant que falli una execució programada, o forçant-ne una.

El patró de la cua de morts

Amb les tres capes ja no perds errors. Però encara falta una cosa: què fa el flux amb l’element que no ha pogut processar.

La resposta dolenta és descartar-lo. La bona és una cua de morts (dead letter queue): una taula on van a parar els elements que han fallat després de tots els reintents, amb prou informació per tornar-los a intentar més tard.

element ── processar ──┬─ èxit ────→ fet
                       └─ error ───→ taula "morts"
                                     (element, motiu, intents, data)

La taula guarda l’element sencer, el motiu de la fallada i quants intents porta. Amb això pots:

• Reprocessar quan la causa s’ha resolt (l’API ja respon, el camp ja ve informat), sense haver de tornar a demanar les dades d’origen.
• Veure patrons: si el 80 % dels morts són el mateix error, no tens un problema de xarxa, tens un problema de dades a origen.

És el mateix principi de la cua de conflictes de Baserow: les excepcions tenen un lloc on esperar i algú que les resol, en comptes de fer petar el flux o —pitjor— desaparèixer.

La reconciliació, perquè els webhooks es perden

Una última xarxa, per als fluxos que reaccionen a esdeveniments. Els webhooks es perden: una caiguda, un desplegament, dos minuts d’n8n fora, i l’esdeveniment no torna. Cap gestió d’errors el recupera, perquè mai va arribar.

L’única defensa és un flux de reconciliació: cada nit, comparar els dos costats i arreglar les diferències. No és redundant amb la resta; és la peça que garanteix que els sistemes acaben quadrant encara que s’hagi perdut un esdeveniment pel camí. És la que gairebé mai es fa i la que sempre acaba fent falta.

La llista abans de deixar un flux sol

Un flux està a punt per a producció quan pots respondre aquestes cinc sense mirar-lo:

1. Quins nodes tenen Retry On Fail, i amb quina espera?
2. Què passa amb els items que fallen enmig d’un lot — s’aparten o tomben la resta?
3. Hi ha un workflow d’error assignat, i on arriba l’avís?
4. On van a parar els elements que no s’han pogut processar, i com es reprocessen?
5. Si es perd un esdeveniment, qui ho detecta, i quan?

Si alguna no té resposta, aquesta és la següent feina, abans d’afegir cap funcionalitat nova.

Continua pel node Code —on es processen els lots que aquí hem après a protegir— o torna al tronc de la guia d’n8n.

Les dades tècniques de configuració (Retry On Fail, Error Trigger, On Error) surten de la documentació d’n8n.