Symfony Messenger / files : le worker oublié est l'incident que je vois le plus après un redémarrage ou un déploiement. L'app répond. Les jobs non. E-mails, PDF, exports, webhooks sortants : tout ce que l'on a mis en asynchrone dépend d'un process (`messenger:consume`) tenu par systemd / supervisor. Cet article dit comment s'en apercevoir (sondes, taille de file), comment le poser, et comment le lier au déploiement.
📬 La file n'est pas la prod
Le HTTP peut être up et le métier à l'arrêt. Une sonde `/health` qui ne regarde pas la file ment. On alerte si `messages` > N ou si la dernière consommation est trop ancienne.
Après deploy : restart du worker, sinon il tourne encore l'ancien code, ou plus du tout.
🛠️ Le poser
Un service par transport si besoin, restart=always, user dédié, logs. Redis/Doctrine transport : on sait lequel, on le sauvegarde si la file est critique pour le métier.
Les jobs qui échouent en boucle : on a un transport d'échec (failure transport), on ne laisse pas exploser la CPU.
- Supervisor/systemd
- Sonde de file
- Restart au deploy
- Failure transport lu
✅ Le worker dans la TMA
Le worker oublié est dans le runbook, à côté des cron. Messenger / files : on le nomme. On ne le « découvre » plus.
Chaque mois, je vérifie que le worker tourne, que la file ne grossit pas et que les messages en échec sont traités. Une alerte part dès que la file dépasse le seuil fixé ensemble.
🔁 Les messages en échec
Un message qui échoue n'est pas perdu : il part dans le transport d'échec. Encore faut-il le lire. `messenger:failed:show` liste ce qui attend, `messenger:failed:retry` le rejoue une fois la cause corrigée.
Je règle les tentatives (3, avec un délai qui augmente) pour qu'une API tierce en panne ne bloque pas toute la file. Un message rejoué doit pouvoir passer deux fois sans envoyer deux factures : on le rend idempotent.
- Retry avec délai
- Failure transport lu chaque semaine
- Messages idempotents
✅ Contrôles d'un worker Messenger fiable
On vérifie que le worker démarre au redémarrage du serveur, qu'il se relance après une erreur et que la taille de la file est surveillée. Chaque point se teste volontairement.
Sauvegarde de la base, accès au serveur à votre nom, journal des messages en échec. Puis 24 à 72 h de suivi de la file. Sans ce suivi, le worker peut mourir à nouveau sans que personne ne le voie.
- Redémarrage du serveur testé volontairement
- Recette avec des messages anonymisés
- Un transport de messages modifié à la fois
- Contrôle humain puis 24 h de suivi de la file
📌 Ce que je refuse sur ce sujet
Je refuse de lancer un worker à la main dans un terminal ouvert. Je refuse de ne pas surveiller une file qui porte des factures. Je refuse les redéploiements qui coupent les workers sans les relancer.
Je refuse aussi de me taire : si le vrai sujet est une file trop chargée ou mal conçue, je le dis. Ce texte n'est pas un prétexte pour vendre un outil de supervision.
Un worker mort, c'est une file qui ment : tout a l'air envoyé, rien n'arrive.
🧭 Questions fréquentes
Faut-il intervenir tout de suite ? Oui si des messages s'empilent depuis des heures (factures, mails, synchronisations). Sinon, ajoutez la supervision du worker avant le prochain redémarrage du serveur.
Peut-on tester sans environnement de recette ? Difficilement : un worker qui consomme des messages en double ou perd des tâches se voit sur une copie avec des messages réels anonymisés, pas en production.
Combien de temps ? Une à deux heures pour installer un superviseur (systemd ou équivalent) et une alerte sur la file. Un « ça redémarre tout seul » sans test de redémarrage ne prouve rien.
