Igor PHP est un outil conçu pour détecter des fuites de cache en worker mode, un problème que PHPStan ne peut pas identifier. Contrairement à PHPStan qui vérifie les types et la cohérence statique du code, Igor analyse le cycle de vie des services en exécution, notamment dans des environnements comme FrankenPHP où un même processus PHP gère plusieurs requêtes sans redémarrage. Cela permet de repérer des mutations d'état involontaires dans des services partagés, évitant ainsi des risques de partage de données entre utilisateurs ou des comportements imprévisibles.
Le billet illustre l'utilisation d'Igor à travers un cas concret : le scan du blog de l'auteur, qui a révélé 269 anomalies brutes réduites à 3 vrais bugs après un tri rigoureux. L'outil, écrit en Go, se distingue en lisant le container Symfony pour différencier les services partagés des instances par requête, puis en signalant toute modification d'état sur les premiers. Cette approche comble une lacune majeure des outils traditionnels, qui ne prennent pas en compte les effets de bord liés au worker mode.
Pour l'installer, deux méthodes sont proposées : un binaire Go autonome ou une dépendance Composer en mode développement. Une configuration minimale est nécessaire, et l'outil peut fonctionner en mode complet (requérant l'exécution de bin/console) ou en fallback si le mode console échoue. Le billet souligne aussi l'importance d'intégrer Igor dans une chaîne CI pour rendre ses rapports exploitables, tout en mettant en garde contre ses limites et particularités d'usage.
Les workers Symfony utilisant Messenger peuvent planter au bout de plusieurs heures — souvent la nuit — à cause de problèmes invisibles comme des fuites mémoire, des connexions externes instables (Redis, base de données) ou des workers laissés actifs trop longtemps sans redémarrage. L’article explique que ces processus sont conçus pour tourner en continu et accumulent progressivement de la mémoire ou des états incohérents, ce qui finit par provoquer un crash ; il recommande donc de mettre en place des limites de messages ou de temps, des redémarrages automatiques via Supervisor/Systemd et une meilleure gestion des erreurs ou des dépendances externes afin de maintenir des workers stables en production.
Tout est dans le titre
Tout est dans le titre
L'auteur propose l'utilisation d'un Listener pour éteindre un worker selon le type d'exception levée.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... toute la série d'articles est excellente