Un message livré deux fois, et la commande part en double
Un broker de messages garantit rarement qu'un message sera délivré une seule fois. Après un timeout, un redémarrage de worker ou un accusé de réception perdu, le même message peut revenir. Si votre handler envoie un e-mail, débite un compte ou crée une facture, ce second passage a un coût réel. Symfony 8.2 apporte une réponse native avec l'inbox de Messenger, complément de l'outbox introduite précédemment.
Rappel : l'outbox, première moitié du pattern
L'outbox règle le problème de l'émission. Plutôt que d'envoyer un message directement au broker, l'application l'enregistre dans la même transaction de base de données que les changements métier. Si la transaction échoue, aucun message ne part. Si elle réussit, le message est garanti d'être transmis plus tard.
Ce mécanisme protège l'envoi, mais il ne dit rien de la réception. Dans un système distribué, la livraison est en général de type « au moins une fois » : un consommateur peut donc recevoir plusieurs fois le même message.
L'inbox : se souvenir de ce qui a déjà été traité
L'inbox est l'autre moitié du pattern. Côté consommateur, l'application garde une trace des messages qu'elle a déjà traités. Quand un message redélivré arrive, Symfony reconnaît qu'il a déjà été pris en charge et l'écarte au lieu de relancer le handler.
La fonctionnalité a été contribuée par Nicolas Grekas (voir la pull request #66957 mentionnée dans l'article d'origine). Elle s'intègre au composant Messenger existant, sans que vous ayez à écrire vous-même la logique de déduplication.
Ce que cela remplace
Sans inbox, on rencontre souvent l'un de ces contournements :
- une table maison qui stocke les identifiants déjà traités, avec sa propre gestion de nettoyage
- des handlers rendus idempotents à la main, un par un
- des contraintes d'unicité en base qui font échouer le traitement plutôt que de l'ignorer proprement
Chacune de ces solutions fonctionne, mais elle dépend de la discipline de chaque développeur et se répète d'un projet à l'autre. Un mécanisme du framework centralise la règle et réduit les oublis.
Bien l'utiliser dans vos projets
Quelques points de vigilance avant d'activer le pattern :
- Identifier les handlers sensibles : paiements, e-mails transactionnels, appels à des API tierces, créations de documents. Ce sont eux qui souffrent le plus d'un double traitement.
- Penser à la transaction : pour que la déduplication soit fiable, l'enregistrement du message traité et les effets du handler doivent rester cohérents entre eux. L'esprit est le même que pour l'outbox.
- Prévoir la rétention : un journal des messages traités grossit. Définissez une durée de conservation adaptée à la fenêtre de redélivrance réelle de votre broker.
- Garder l'idempotence en tête : l'inbox est un filet de sécurité, pas une excuse pour écrire des handlers dangereux à rejouer. Les effets de bord vers des systèmes externes méritent toujours une réflexion.
Le bon réflexe consiste à tester le comportement avec des redélivrances provoquées : arrêt brutal d'un worker, message rejoué manuellement, échec après traitement mais avant acquittement.
Conclusion
Avec l'outbox côté émission et l'inbox côté réception, Messenger couvre désormais les deux extrémités d'un flux asynchrone fiable. Si vous préparez une montée vers Symfony 8.2, repérez dès maintenant les handlers qui ne supportent pas d'être exécutés deux fois : ce sont les premiers candidats à l'inbox. Pour le détail de la fonctionnalité, consultez l'article d'origine : New in Symfony 8.2: Messenger Inbox.
