Le corbeau part, c'est déjà ça. Mais il part pendant la requête : le parchemin de la guilde attend que l'oiseau soit préparé, nourri et lâché avant de recevoir sa réponse. Et si la volière est encombrée, la guilde attend.
Désormais, le message ira dans une file d'attente. La réponse part aussitôt ; un travailleur s'occupe des corbeaux à son rythme.
Votre mission
Dans config/packages/messenger.yaml :
- déclarez un transport
async, qui garde les messages dans la base (doctrine://default) ; - routez
App\Message\ConfirmationDemandeevers ce transport ; - pendant les tests, remplacez ce transport par
in-memory://.
Rien à changer dans le message, le handler ou le contrôleur : c'est tout l'intérêt.
Voir la file, puis la vider
Réservez depuis l'onglet Requêtes : la volière (/voliere) reste vide, le corbeau attend. Dans la console :
messenger:stats messenger:consume async --limit=1
La première commande compte les messages en attente, la seconde en traite un puis s'arrête. Rechargez la volière : le corbeau est parti.
En production, ce messenger:consume tourne en permanence, surveillé par un superviseur.
Pourquoi in-memory:// pendant les tests ?
Un test ne doit ni écrire dans la vraie file, ni dépendre d'un travailleur. Le transport in-memory:// garde les messages dans la mémoire du test : on peut vérifier qu'un message a été envoyé, et le traiter au moment choisi.
À noter
Le DSN doctrine://default crée sa table tout seul au premier message. En production, on préfère ?auto_setup=0 et une commande messenger:setup-transports au moment du déploiement : l'application ne modifie pas la base en pleine exécution.