Le corbeau qui se perd

Un corbeau n'arrive pas toujours. Les vents tournent, les tours sombres brouillent les routes… et certaines contrées sont tout simplement hors de portée.

La taverne s'est dotée d'un service Voliere : c'est lui qui lâche les oiseaux. Quand la destination est inaccessible, il lève une VoliereIndisponible. Aujourd'hui, une telle erreur ferait disparaître la confirmation. Il faut réessayer, puis, si rien n'y fait, mettre le message de côté au lieu de le perdre.

Votre mission

1. Dans le handler, confiez l'envoi à la volière ($this->voliere->envoyer(...)). Laissez l'exception remonter : c'est le signal d'échec.
2. Dans messenger.yaml :
   • donnez au transport async une retry_strategy : 2 réessais, 1 seconde d'attente, doublée à chaque fois ;
   • ajoutez un transport echoues, et désignez-le comme failure_transport ;
   • pendant les tests, les deux transports vivent en mémoire, avec un délai de réessai nul : un test ne doit pas passer son temps à attendre.

Ce que fait Messenger tout seul

Quand un handler lève une exception, le worker ne jette pas le message : il le remet en file avec un délai, et recommence. Après le dernier réessai, le message part dans le transport des échecs. Rien n'est perdu, et la file principale n'est pas bloquée.

Chaque réessai laisse une trace sur l'enveloppe, un tampon (RedeliveryStamp) : on sait combien de fois le message a déjà été tenté.

Dans la console

messenger:consume async --limit=5
messenger:failed:show
messenger:failed:retry

La première traite la file (essayez une réservation pour Sauron dans l'onglet Requêtes). La deuxième liste les messages mis de côté, la troisième les rejoue — une fois les vents calmés.

Le bon réflexe

Réessayer n'a de sens que pour une panne passagère : une volière encombrée, un service qui répond mal. Une erreur qui se reproduira à l'identique (une donnée invalide, par exemple) ne mérite pas de réessai : mieux vaut la mettre de côté tout de suite.