Salut à tous,
J’ai un problème de fiabilité avec les workflows déclenchés par webhook dans n8n.
Ma configuration ressemble à : Webhook → Traiter les données → Requête HTTP → Base de données
Le service externe relance le webhook s’il n’obtient pas une réponse assez rapide, ce qui provoque parfois :
• Exécutions de workflow en double
• Insertions en double dans la BD
• Appels API/e-mails en double
La charge utile inclut un ID d’événement :
{
“event_id”: “evt_12345”,
“user_id”: 42
}
Actuellement, si le même webhook est envoyé deux fois, les deux exécutions s’exécutent complètement.
J’essaie de déterminer la meilleure approche de production pour :
• La déduplication
• Empêcher le traitement simultané du même événement
• Gérer les tentatives en toute sécurité
J’ai envisagé :
• Stocker les event_ids traités dans la BD
• Utiliser des verrous Redis
• Traitement basé sur une file d’attente
• Retourner les réponses webhook immédiatement et traiter de manière asynchrone
Pour les personnes qui gèrent des systèmes de webhook à haut volume dans n8n :
• Quel modèle s’est avéré le plus efficace pour prévenir les exécutions en double et les effets secondaires ?
), veuillez contacter le support à help@n8n.io --→
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
- Version de n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
Bonjour @Keira_Becky L’approche la plus fiable est généralement : Webhook → Enregistrer/vérifier event_id → Traiter
L’idée clé est de traiter event_id comme un identifiant unique.
Stockez event_id dans votre base de données avec une contrainte UNIQUE avant de traiter quoi que ce soit.
Exemple : INSERT INTO webhook_events (event_id)
VALUES ({{$json.event_id}})
ON CONFLICT DO NOTHING;
Si l’insertion réussit → traiter le workflow
Si elle existe déjà → l’ignorer
Cela permet de : Prévenir le traitement en double
Gérer les tentatives de webhook en toute sécurité
Arrêter les e-mails/appels API/insertions DB en double
Vous pouvez également essayer de retourner la réponse webhook rapidement et traiter le travail lourd de manière asynchrone si possible. Cela réduit les tentatives du service externe.
Bienvenue @Keira_Becky dans notre communauté ! Je m’appelle Jay et je suis un créateur vérifié n8n.
L’approche de contrainte unique de base de données mentionnée par Niffzy est solide. Pour une approche pure n8n sans configuration supplémentaire de base de données, vous pouvez utiliser $getWorkflowStaticData('global') pour suivre les ID d’événements traités directement dans le workflow - stockez l’event_id dans un nœud Set vers l’objet de données statiques, puis vérifiez à chaque exécution avant le traitement. Cela fonctionne pour des volumes modérés mais ne s’adapte pas aux débits élevés.
Pour la production, la combinaison la plus simple est : retourner immédiatement la réponse webhook en utilisant le nœud Respond to Webhook (défini sur « Respond First »), puis continuer le traitement lourd après - cela élimine la plupart des nouvelles tentatives à la source. Ajoutez par-dessus une vérification de base de données avec une contrainte UNIQUE sur event_id comme décrit par Niffzy, et vous aurez couvert à la fois la prévention des tentatives et la déduplication réelle. Si vous utilisez l’auto-hébergement avec le mode de file d’attente activé, définissez également EXECUTIONS_TIMEOUT et les limites de concurrence pour éviter les accumulations lors des pics.
Excellente analyse du problème. Voici l’approche en production que j’ai utilisée et qui répond proprement à vos trois préoccupations :
1. Dédoublonnage basé sur la base de données (votre meilleur choix pour la plupart des configurations)
Au tout début de votre workflow, avant tout traitement, effectuez une recherche en base de données sur event_id. Si une ligne existe avec le statut processed ou processing, répondez immédiatement avec 200 et arrêtez. Si rien n’est trouvé, insérez une ligne avec le statut processing — cela agit comme votre verrou.
La clé est d’effectuer l’insertion avec une contrainte UNIQUE sur event_id pour que les exécutions concurrentes fassent la course pour insérer et qu’une seule gagne. Le perdant reçoit une violation de contrainte que vous capturez et vous quittez proprement.
2. Répondez au webhook immédiatement (nœud Respond to Webhook)
Utilisez le nœud “Respond to Webhook” de n8n tôt dans votre workflow — avant le traitement lourd — pour retourner 200 instantanément. Cela empêche le service externe de dépasser le délai d’attente et de réessayer en premier lieu. Ensuite, continuez le traitement dans la même exécution. Cela seul élimine la plupart des scénarios de duplication.
3. Mode file d’attente pour une véritable protection de concurrence
Si vous êtes en auto-hébergement et avez besoin d’un dédoublonnage infaillible sous charge, exécutez n8n en mode file d’attente (avec Redis/Bull). Combiné à la vérification de base de données ci-dessus, vous obtenez un traitement sérialisé sans conditions de course.
Recommandation pratique :
- Répondre au webhook tôt → élimine la plupart des retentatives à la source
- Vérification de dédoublonnage en base de données avec contrainte UNIQUE → gère le reste
- Les verrous Redis sont excessifs sauf si vous traitez des milliers d’événements/min
La combinaison de réponse rapide + écritures en base de données idempotentes est de qualité production et ne nécessite pas Redis.