La nouvelle règle de remise apparaît dans le portail, mais les devis envoyés en arrière-plan utilisent encore l’ancien calcul. Le déploiement a terminé sans erreur et la commande messenger:stop-workers a affiché un succès. Pourtant, un processus démarré avant la livraison continue à consommer les demandes. Dans cette situation illustrative, vérifier uniquement la page web laisse passer une application qui travaille avec deux générations de code.
Ce diagnostic concerne une application Symfony qui confie des tâches à Messenger et dont les releases peuvent changer de répertoire ou de conteneur. Le symptôme mérite une investigation lorsque le résultat asynchrone contredit la version attendue : documents, notifications, imports ou calculs différés. Il ne permet pas d’accuser immédiatement le cache. Un traitement déjà engagé, une commande de lancement figée ou une autre machine peuvent produire une observation voisine.
Le risque est de confondre un signal d’arrêt écrit avec le remplacement effectif du worker : la livraison doit prouver quelle version réalise le prochain traitement. Nous suivons le signal jusqu’à son lecteur, puis le lancement du remplaçant. Un exercice local de neuf cas et 28 assertions éprouve la visibilité dans Symfony Cache ; il ne démarre aucun worker Messenger, aucun broker et aucun service client.
Le développement web sur mesure comprend aussi la cohérence des traitements qui ne passent pas par l’écran. Une reprise d’application Symfony peut commencer par ce défaut ciblé : retrouver les versions actives, établir le chemin d’arrêt et qualifier une livraison observable avant de refaire toute l’infrastructure.
Pour qui : le portail change, les traitements différés restent anciens
Partir d’un résultat métier attribuable
Une équipe commerciale constate que le PDF d’un devis ne reprend pas la remise affichée. Le responsable applicatif retrouve le dossier, sa demande de génération et la version déclarée par le traitement. Cet exemple fictif évite de réduire le problème à un nom de processus. Ce qui compte d’abord est la règle appliquée au document remis, puis le code et les données qui permettent d’expliquer cette règle.
Deux signaux faibles orientent la recherche : l’anomalie se concentre sur les travaux asynchrones, ou seuls certains résultats produits après la livraison restent anciens. Il faut conserver leur identifiant et leur heure. Un dossier calculé avant le changement peut être conforme à son contrat historique. Comparez des demandes dont le moment de prise en charge est connu avant d’attribuer une erreur à la génération du worker.
Qualifier ce qui doit être repris maintenant
Le cas intéresse une DSI, un éditeur ou une équipe produit qui reprend un applicatif dont le déploiement historique reste partiellement manuel. Il est plus urgent lorsqu’un ancien calcul engage un prix, une validation ou une communication externe. Une prévisualisation interne a une conséquence différente. Le métier nomme les sorties concernées ; l’exploitation confirme où tournent les consommateurs et qui possède leur lancement.
Priorisez la cohérence d’un flux critique avant une migration générale vers Docker ou Kubernetes. La modernisation peut venir ensuite si elle réduit un risque démontré. Un redémarrage maîtrisé peut suffire pour rétablir une tâche, mais ne ferme pas le diagnostic si la prochaine release reproduit le défaut. Le premier résultat attendu est une frontière vérifiable entre les anciennes demandes et le traitement repris.
Anatomie : du code livré au processus qui produit le résultat
Séparer quatre observations souvent mélangées
Le fichier livré, la version servie en HTTP, la génération du consommateur et le résultat métier sont quatre observations distinctes. Le frontend peut présenter la nouvelle règle tandis qu’un traitement persistant travaille encore depuis une ancienne release. Tracez la révision chargée au démarrage dans le contexte du processus. Reliez ensuite ce contexte aux demandes qu’il prend effectivement en charge, sans déduire sa version d’un badge affiché par le portail.
La fiche de diagnostic conserve le service, l’hôte, l’identifiant de processus ou de conteneur, l’heure de démarrage et la révision applicative. Ces valeurs doivent provenir du runtime observé. Une variable qui annonce la dernière livraison ne constitue pas une preuve du code chargé si elle est réécrite indépendamment. Le responsable choisit un identifiant de release attaché au paquet réellement démarré et le vérifie sur une tâche témoin.
Distinguer l’arrêt demandé de la relève attendue
Dans le code de StopWorkersCommand en version 8.1.0, la commande écrit un horodatage dans son pool de cache puis renvoie zéro. Elle ne collecte pas d’accusé de sortie de chaque processus. Le succès visible ne suffit donc pas à établir que tous les consommateurs ont lu la demande ou quitté leur ancienne génération.
Pour une livraison, définissez une preuve de relève indépendante : les processus attendus ont quitté l’ancienne release, les remplaçants ont démarré depuis la cible et une demande contrôlée produit le résultat prévu. Une équipe peut obtenir ces observations avec son gestionnaire de processus et sa journalisation existants. L’objectif n’est pas d’ajouter une nouvelle plateforme de monitoring avant de pouvoir répondre à ces trois questions.
Le signal peut être écrit dans un cache que l’ancien worker ne lit pas
Retrouver le lecteur et sa condition d’arrêt
Le listener de redémarrage Messenger 8.1.0 consulte la clé workers.restart_requested_timestamp. Si elle manque, il ne demande pas l’arrêt. Si elle existe, son horodatage doit être strictement postérieur au démarrage du worker. Cette comparaison décrit la condition du composant inspecté ; elle ne certifie ni la visibilité de votre pool ni le lancement ultérieur d’un remplaçant.
La question de diagnostic devient précise : le lecteur actif peut-il retrouver la valeur écrite par la commande exécutée lors de la livraison ? Notez les deux contextes au lieu de tester seulement une console fraîche. Cette dernière peut lire son propre signal et donner l’impression que tout fonctionne. Le processus ancien reste l’observateur pertinent pour établir la portée de l’instruction qui lui était destinée.
Comparer espace de noms et emplacement du stockage
Notre exercice distingue deux causes de visibilité absente. Des espaces de noms différents isolent les clés même dans un même répertoire de stockage. À l’inverse, un nom identique ne réunit pas deux stockages séparés. Les neuf cas ci-dessous montrent ces frontières avec l’adaptateur FilesystemAdapter réellement installé. Les noms de release y sont fournis explicitement pour éprouver cette propriété, sans reproduire la compilation complète d’une application.
Paradoxalement, choisir le même libellé de pool dans deux configurations ne prouve pas qu’elles rejoignent le même contenu. Le diagnostic relève l’adaptateur, sa destination effective et l’identité utilisée pour les clés. Sur plusieurs machines, un chemin de fichiers identique peut désigner des disques distincts. Ne recopiez aucune connexion sensible dans un ticket public ; conservez seulement les éléments nécessaires pour comparer les contextes d’exécution.
Les répertoires de release peuvent changer l’identité du cache
Vérifier une configuration compilée, pas seulement le YAML
La référence Symfony de cache.prefix_seed donne une valeur par défaut construite à partir de kernel.project_dir et kernel.container_class. Cette option intervient dans l’identité des clés à la compilation du conteneur. Modifier sa valeur après compilation ne change pas le conteneur déjà produit. Le fichier source et le runtime doivent donc être rapprochés avant de conclure.
Une identité stable doit appartenir à l’application et à son environnement, plutôt qu’à un dossier de livraison éphémère. Gardez les environnements et applications sans relation isolés. Partager volontairement un espace de noms exige de connaître les consommateurs concernés. Le test local ne valide pas une valeur de configuration universelle : il rend visible une frontière que votre équipe doit vérifier sur ses pools et ses conteneurs compilés.
Éviter une correction que seule la nouvelle release reçoit
Une première correction peut stabiliser le nom utilisé par les releases suivantes tout en laissant un ancien consommateur sur son ancienne identité. Préparez explicitement cette transition avec l’exploitation : inventaire des processus concernés, mode d’arrêt qu’ils peuvent recevoir et cible de relance. Il faut observer leur sortie. L’intention écrite dans le nouveau fichier de configuration ne suffit pas à faire rejoindre le nouveau contexte par un processus déjà démarré.
La documentation de déploiement Messenger recommande de renouveler les workers et de conserver une visibilité commune du cache entre releases. Elle précise aussi le rôle d’un gestionnaire de processus pour leur relance. Faites correspondre ces recommandations à votre stratégie effective : dossiers successifs, services persistants ou conteneurs remplacés ne donnent pas les mêmes observations à collecter.
Exercice corrigé : neuf lectures du signal dans Symfony Cache
Poser un laboratoire dont la portée est explicite
L’essai utilise PHP 8.5.6 et Symfony Cache 8.1.0. Chaque cas crée deux adaptateurs de fichiers, écrit un horodatage puis vérifie ce que l’observateur retrouve. Le temps de démarrage et le signal sont fictifs, choisis pour rendre les comparaisons déterministes. Le laboratoire applique ensuite une condition temporelle explicite inspirée du listener inspecté. Ce modèle d’observateur n’est pas un worker Messenger en cours de consommation.
Le composant Messenger n’est pas installé dans cet environnement d’exercice. Aucun broker, aucune file de messages ni aucun gestionnaire de processus ne sont exécutés. Les 28 assertions vérifient les écritures, les lectures et les décisions du modèle. La compilation de cache.prefix_seed reste hors de l’expérience. Cette limite évite de transformer une preuve de visibilité en certification de votre séquence de déploiement.
| Cas | Configuration | Signal retrouvé | Arrêt demandé par le modèle |
|---|---|---|---|
| 1 | Noms release_a et release_b ; même stockage | Non | Non |
| 2 | Nom sav_prod commun ; même stockage ; signal récent | Oui | Oui |
| 3 | Nom commun ; stockages host_a et host_b | Non | Non |
| 4 | Signal à 110 ; démarrage à 120 | Oui | Non |
| 5 | Signal et démarrage à 110 | Oui | Non |
| 6 | Démarrage à 110 ; signal à 110,5 | Oui | Oui |
| 7 | Applications sav_prod et sales_prod distinctes | Non | Non |
| 8 | Environnements sav_prod et sav_staging distincts | Non | Non |
| 9 | Nom et stockage communs ; signal supprimé avant lecture | Non | Non |
Interpréter les contre-exemples sans élargir la preuve
Dans les cas 1 et 3, l’écriture réussit mais le lecteur ne retrouve rien. Ils matérialisent deux vérifications à mener lorsque la commande paraît avoir fonctionné. Le cas 2 montre la visibilité commune, tandis que les cas 4 à 6 distinguent présence et comparaison temporelle. Une valeur visible ne doit pas provoquer mécaniquement la sortie d’un processus démarré après la demande.
Le dernier cas supprime volontairement le signal local après son écriture. Il démontre que lire après une suppression n’observe plus la demande ; il ne prouve pas qu’une commande de purge de votre application produit cet ordre précis. Si vous suspectez un nettoyage concurrent, retrouvez sa portée et sa chronologie. La recette doit reproduire l’enchaînement constaté, avec des fichiers fictifs et sans supprimer le cache d’un service client.
Le remplaçant doit démarrer depuis la release attendue
Examiner la commande de lancement réellement utilisée
L’arrêt réussi laisse une autre question : d’où repart le service ? Une configuration de lancement peut conserver un chemin absolu vers une ancienne release, même si le portail sert la nouvelle. Relevez l’exécutable PHP, le répertoire de travail, les arguments et le paquet applicatif effectivement choisis. Le nom du programme dans Supervisor ou systemd est un repère d’exploitation ; il ne prouve pas le chemin chargé.
Après la relève, comparez l’identité annoncée au démarrage avec la révision attendue et l’image ou les fichiers du service. Un nouveau PID qui exécute le même ancien paquet ne corrige pas la règle métier. La recette garde donc une demande témoin et son résultat, au-delà de l’état « running ». Elle vérifie aussi que les consommateurs attendus sont présents, sans lancer un second service concurrent par commodité de diagnostic.
Attribuer l’action à la bonne équipe
Le développeur établit où se trouve la règle et comment identifier sa génération. L’exploitation possède le cycle de vie du service et son lancement. Le métier confirme le résultat de la tâche choisie. Ce partage permet de corriger un déploiement historique sans supposer que la personne qui lance la console connaît toutes les machines. Si un prestataire héberge les workers, incluez ses observations avant de déclarer la relève terminée.
Une règle de remplacement doit couvrir chaque groupe consommateur pertinent, y compris ceux qui tournent rarement. Un worker documentaire démarré par une tâche planifiée peut suivre un autre chemin que celui des notifications continues. L’inventaire mentionne fréquence, responsable et manière de vérifier la version. Différez la standardisation des services secondaires si nécessaire, mais explicitez lesquels restent hors de la livraison validée.
Rapprocher les sorties produites pendant la coexistence des versions
Ne pas rejouer un devis parce que son worker était ancien
Pour le devis illustratif, retrouvez la version de règle attendue au moment convenu par le contrat. Certains dossiers peuvent conserver une grille historique, d’autres doivent appliquer la nouvelle. La génération du processus est une donnée d’enquête, pas une autorisation de remplacement commercial. Le responsable vérifie le document remis, son statut et une éventuelle action du destinataire avant de choisir une correction.
Dans un cas concret de devis, une relecture peut identifier une sortie erronée sans savoir si l’envoi a réellement abouti. Gardez ce résultat inconnu distinct d’un échec confirmé. Un rejeu aveugle peut ajouter un second courrier ou un nouveau document au lieu de réparer le premier. La reprise demande une règle d’idempotence ou de rapprochement adaptée au domaine et au canal ; cette règle ne résulte pas du seul redémarrage du consommateur.
Chiffrer l’impact à partir des dossiers concernés
Le coût caché rassemble le temps pour identifier les sorties, les contrôles métier, les documents à remplacer et les échanges nécessaires avec les destinataires. Le budget de reprise doit partir de ce périmètre constaté. Mesurez ces postes sur les dossiers effectivement concernés. Le volume total de la file ne représente pas le nombre de résultats faux. Un incident sur quelques devis engageants peut réclamer plus de travail qu’un retard sur une grande série de prévisualisations internes.
Le suivi sépare durée de coexistence des générations, nombre de demandes attribuées à chacune et décisions de reprise. Ces indicateurs rendent le bilan utile pour le delivery suivant. Ne présentez pas une baisse de tickets comme une preuve de correction si la nouvelle règle n’a pas été exercée. Une transaction fictive validée par le métier apporte une observation plus directe qu’une période sans plainte sur un service peu sollicité.
Erreurs fréquentes : réparer le symptôme sans vérifier le processus
Purger le cache avant d’en relever les différences
Une purge immédiate peut effacer une observation utile et mélanger plusieurs causes. Commencez par identifier les pools et les générations, puis reproduisez la visibilité dans un contexte maîtrisé. Le laboratoire montre qu’une suppression après écriture change le résultat du lecteur. Il ne fournit aucune permission pour nettoyer un environnement partagé, dont les sessions, les calculs et d’autres usages peuvent dépendre de règles propres.
Changer simultanément namespace, stockage, commande et stratégie de lancement complique aussi la lecture du correctif. Préférez une correction dont chaque dépendance est connue et une recette qui conserve un contre-exemple. L’équipe peut ensuite consolider son architecture. Le gain vient de la capacité à expliquer pourquoi le prochain consommateur rejoint la bonne génération, pas du nombre de réglages modifiés pendant l’incident.
Confondre arrêt forcé et fin d’un traitement
Un processus disparu ne prouve pas que sa dernière tâche a produit un résultat complet. Si une interruption directe a été nécessaire, retrouvez les demandes engagées et leur état avant tout rejeu. Le domaine peut avoir écrit une partie du résultat ou appelé un service tiers. La procédure de reprise s’appuie sur ces effets et sur les mécanismes d’acquittement du transport réellement utilisé, qui ne sont pas testés ici.
La compatibilité des messages reste également une question séparée. Un remplaçant peut charger la bonne release tout en refusant un ancien format en attente. Notre diagnostic s’arrête à la visibilité du signal et à l’identification de la génération. Il doit être complété par une recette des contrats de messages si la livraison les modifie, afin que le retour arrière et la progression de la file gardent un sens métier.
Plan d’action : prouver la relève sur un flux avant la prochaine release
Constituer un témoin avec le responsable de l’application
Choisissez une tâche fictive dont le résultat varie de manière compréhensible entre les deux versions, par exemple un devis de test qui applique une règle interne différente. Le responsable métier précise le résultat attendu ; l’équipe technique identifie le consommateur, sa révision chargée et son contexte de cache. N’envoyez pas ce document à un prospect pour valider l’infrastructure. Une sortie interne suffit pour observer le parcours convenu.
Le runbook décrit l’entrée de recette, un identifiant de devis fictif, et la sortie attendue, un PDF interne portant la règle convenue. Il attribue la responsabilité du lancement à l’exploitation et celle du résultat au métier. La journalisation relie identifiant de demande, révision chargée et contexte du consommateur, sans recopier le document client ni ses données. L’exploitation relève ensuite la commande de lancement, les services concernés et les éléments qui démontrent une visibilité commune du signal. Le développeur rapproche la configuration compilée et les pools réellement utilisés. Si le défaut vient d’un ancien chemin de relance, corrigez cette dépendance plutôt que le cache au hasard. Le dossier garde l’hypothèse retenue, le contre-exemple reproduit et les critères d’arrêt du diagnostic.
Fermer la recette avec une décision explicite
- À faire d’abord : retrouver le contexte du consommateur ancien et le résultat qui justifie l’enquête.
- À corriger ensuite : la différence de cache ou le chemin de relance effectivement démontré, puis observer la nouvelle génération.
- À refuser : rejouer les sorties externes dont le résultat reste inconnu sans une règle de rapprochement.
- À différer : une migration générale d’hébergement tant que ce flux et sa reprise ne sont pas qualifiés.
La livraison est acceptée sur ce flux lorsque l’ancienne génération a quitté le périmètre attendu, que les remplaçants annoncent la bonne révision et que la demande témoin produit le résultat confirmé. Fixez une fenêtre d’observation cohérente avec la durée habituelle des tâches, sans recopier un délai universel. Si un consommateur reste inconnu ou si le résultat ne peut pas être attribué, la recette garde cette réserve et le responsable correspondant.
Préparez enfin le rollback : paquet à relancer, dépendances requises, compatibilité des demandes en attente dans la file, sorties déjà émises et procédure de rapprochement. Le runbook précise le responsable de cette décision et le seuil d’arrêt retenu pour la recette, par exemple toute demande témoin dont la révision reste inconnue. Le rollback du code ne rappelle pas les documents remis. Conservez cette distinction dans le runbook et répétez la recette lors d’une livraison qui change le lancement ou le cache. Une routine courte, exécutée sur les vrais rôles de l’application, rend la prochaine reprise plus prévisible.
Lectures complémentaires : de la file au cycle de livraison
Relier la génération active aux responsabilités du run
Le guide Messenger Symfony et exploitation des tâches traite le choix d’asynchronisme, les états et les reprises. Il complète l’identification d’un worker par le contrat de ce qu’il réalise. La visibilité d’une instruction d’arrêt reste un contrôle plus étroit : elle ne répond pas à la question des messages anciens compatibles avec le nouveau code.
Le guide services web, queue, cron et workers aide à distinguer les rôles qui partagent un paquet. Cet inventaire permet de ne pas oublier un consommateur au moment de vérifier la relève. Le témoin présenté ici reste limité aux clés du cache ; il ne certifie aucune image ni topologie Docker particulière.
Préparer une reprise qui couvre les usages concernés
Le guide conteneurisation d’un projet Symfony examine la reproductibilité et les limites du changement d’environnement. Un conteneur remplaçable peut simplifier le cycle de vie, mais la décision doit suivre les responsabilités et les preuves attendues. Elle ne remplace pas l’attribution d’une tâche à la révision qui l’a traitée.
Le guide déploiement d’application par rôle et par site élargit la recette aux équipes utilisatrices. Un poste pilote peut confirmer le nouveau portail alors qu’un rôle de fond manque encore au contrôle. Ce diagnostic apporte précisément une observation à ajouter lorsque des tâches différées influencent le résultat remis au métier.
Conclusion : valider la version qui traite, après le signal d’arrêt
Le succès de messenger:stop-workers et la disparition d’un ancien processus appartiennent à deux étapes différentes. Comparez les contextes du signal et de son lecteur, puis vérifiez le paquet utilisé par le remplaçant. Le résultat d’une tâche attribuable ferme cette chaîne. Cette démarche permet de distinguer un défaut de visibilité, une relève lancée au mauvais endroit et une règle historique conservée volontairement.
Les neuf cas locaux montrent des écritures réussies que l’observateur ne retrouve pas, ainsi que la différence entre un horodatage présent et postérieur au démarrage. Ils vérifient Symfony Cache et une condition temporelle explicite. Aucun worker Messenger réel, transport de messages, compilateur de configuration ou gestionnaire de processus n’a participé à l’essai : ces éléments restent à recetter dans votre application.
Une reprise ciblée de votre application Symfony peut livrer l’inventaire des consommateurs, la comparaison des caches effectifs, une procédure de relève et un témoin métier. Le périmètre se construit à partir des versions observées et des responsabilités d’exploitation, avec vos prestataires lorsqu’ils possèdent une partie du lancement.
Avant une refonte complète, rendez le prochain traitement explicable et le retour arrière praticable. Dawap accompagne le développement d’applications web métier en reliant code, tâches asynchrones et résultats attendus. Le point de départ est un flux qualifié, dont la version active et la conséquence peuvent être vérifiées par les équipes qui l’exploitent.
