Notificacions duplicades no signifiquen necessàriament dos enviaments de formulari. Un únic submit pot disparar dues accions de correu, un retry pot repetir un job o dos connectors escoltar el mateix esdeveniment. Assigna IDs estables abans de desactivar hooks a l’atzar.
Compta submissions i correus per separat
Comprova entrades/request IDs. Dos missatges d’una entrada és problema d’acció; dues entrades és deduplicació navegador/servidor.
Revisa accions configurades
Builders poden tenir diversos correus o notificació admin/usuari al mateix destinatari.
Comprova AJAX i reintents
Doble clic, timeout frontend o retry JS poden repetir el submit sense una clau d’idempotència.
Inspecciona cues i webhooks
Jobs en segon pla poden reintentar-se encara que el primer enviament arribés. Registra job/event IDs i message IDs.
Busca hooks duplicats
Snippets, CRM o connectors SMTP poden enganxar una segona notificació al mateix esdeveniment.
Deduplica a la capa correcta
Usa identitat del submission/esdeveniment amb finestra acotada. No bloquegis qualsevol mateix destinatari+assumpte perquè dos leads legítims poden coincidir.
Usa la traça end-to-end i el diagnòstic sense dades personals.
Construeix un ledger de l’esdeveniment duplicat
Per a una notificació duplicada registra submission ID, nombre de requests, entrades desades, IDs d’accions, jobs/cua i message IDs del proveïdor. Dos IDs de proveïdor des d’una acció suggereixen retry de transport; dues accions, configuració; dos submissions, deduplicació navegador/servidor. El ledger porta la reparació a la capa correcta.