Une notification répétée peut-elle créer deux tâches ou deux réservations ?

Une demande métier et ses tentatives techniques sont deux compteurs

Nous demanderions une règle d’unicité observable avant d’automatiser la création d’engagements. Une erreur de réseau peut laisser l’émetteur sans confirmation alors que l’objet a déjà été créé. Relancer aveuglément la création risque alors de produire un doublon.

Le protocole n’impose pas une nouvelle architecture : une clé de demande reconnue et un rapprochement peuvent suffire. Ce qui compte est de retrouver le même objet après répétition et de distinguer cette répétition d’une véritable nouvelle demande. Le nom identique n’est pas, à lui seul, une preuve de doublon.

Trois envois, puis une modification réelle

Faites transmettre trois fois le même événement fictif avec sa référence. Vérifiez qu’un seul objet a été créé. Envoyez ensuite une vraie modification de date et contrôlez qu’elle modifie cet objet au lieu d’en créer un nouveau. Enfin, soumettez une deuxième demande au même titre mais à une autre référence : elle doit suivre sa propre règle.

Nous retiendrions un connecteur dont les exceptions peuvent être rapprochées par le responsable opérationnel. Il faut aussi traiter les événements manquants ; la protection contre les répétitions n’est pas une garantie d’exhaustivité des échanges.

Asana indique retenter l’envoi d’un webhook lorsque le serveur ne répond pas avec succès dans le délai prévu.