Una versión anterior añadió un límite a los logs de build. Diez mil líneas, ocho megabytes, se descartan las más antiguas y se deja un marcador que indica cuánto se tiró. Salió en verde. Bajo una prueba de carga que en su momento había provocado un OOM del proceso a 7,3 GB, la memoria residente ahora alcanzaba un pico de 201 MB. Caso cerrado.
Después, un tester desplegó una aplicación cuyo Dockerfile ejecutaba RUN seq 1 2000000 y luego miró la base de datos. La columna build_log contenía 13,95 MB repartidos en 1 882 590 líneas. Ningún marcador. El límite que había pasado todos los tests y acotado la RSS en la prueba de carga no había hecho absolutamente nada en el camino que de verdad persiste los logs.
Esta es una historia sobre dónde vive un valor, y sobre por qué «el test pasa» y «el arreglo funciona» son afirmaciones distintas.
Dos consumidores, un solo stream
Cuando sh0 construye una imagen Docker, lee la respuesta del daemon frame a frame. Cada línea de log va a dos sitios:
rustif let Some(stream) = output.stream {
let trimmed = stream.trim().to_string();
if !trimmed.is_empty() {
if let Some(tx) = log_tx {
let _ = tx.try_send(trimmed.clone()); // (1) vista en vivo
}
logs.push(trimmed); // (2) acumulador acotado
}
}El camino (2) es un CappedLogs — una deque acotada que descarta la línea más antigua cuando supera las 10 000 líneas u 8 MB, contando los descartes. Ese es el límite que añadió la versión anterior, y es correcto. build_image lo devuelve como BuildResult.logs.
El camino (1) es un canal mpsc que alimenta una tarea en segundo plano — el «flusher» — que escribe en la base de datos cada 500 ms para que el panel pueda seguir el build en vivo.
Aquí está todo el bug, en el flusher:
rustupdate_deployment_field(&pool, &dep_id, move |dep| {
let existing = dep.build_log.clone().unwrap_or_default();
dep.build_log = Some(format!("{existing}{batch}\n"));
}).await.ok();En cada tick: leer la columna entera, clonarla, añadir el nuevo lote y volver a escribirla. No hay ningún límite en ninguna parte de este camino. El CappedLogs del camino (2) — el que tiene la cota y el marcador — se devuelve a quien llama en caso de éxito y, para el log persistido, se ignora. La base de datos la alimenta el canal, que no está acotado.
Así que el límite existía. Estaba bien escrito y bien testeado. Solo que protegía un valor que el camino de éxito tiraba a la basura.
Por qué todas las comprobaciones lo pasaron por alto
- Los tests unitarios ejercitaban
CappedLogsdirectamente. Demostraban que la deque se acotaba a sí misma. No podían ver que el pipeline persiste una cadena distinta. - La prueba de carga medía la RSS, y la RSS estaba acotada — porque con 14 MB de log acumulado, el transitorio del clon por tick ronda los 28 MB, cómodamente dentro de «un par de cientos de MB». La memoria se veía bien precisamente porque la fila aún no era catastróficamente grande; el crecimiento es lineal y no acotado, pero un build de unos segundos nunca llega al precipicio. La métrica que había detectado el incidente original era la métrica equivocada para este defecto.
- La aserción del marcador — un punto de checklist que buscaba
[sh0: N earlier lines dropped]en el log persistido — nunca podía pasar en un build exitoso, porque esa cadena solo existe en el Vec descartado. Llevaba fallando en silencio desde el día en que se escribió.
Tres señales en verde, una fila de 14 MB. Ninguna de las señales mentía; todas respondían a una pregunta vecina a la que importaba.
El arreglo: acotar lo que se conserva
El movimiento correcto es convertir al propio flusher en el acumulador acotado. Los tres puntos de llamada del streaming (git, Dockerfile, upload) habían derivado en tres copias del flusher idénticas byte a byte, así que se fusionaron en un único helper, y la concatenación pasó a ser un re-acotado:
rustasync fn flush_build_log_batch(pool: &Arc<DbPool>, dep_id: &str, pending: &mut Vec<String>) {
if pending.is_empty() { return; }
let batch = redact_secrets(&std::mem::take(pending).join("\n"));
update_deployment_field(pool, dep_id, move |dep| {
let existing = dep.build_log.take().unwrap_or_default();
dep.build_log = Some(cap_build_log(format!("{existing}{batch}\n")));
}).await.ok();
}cap_build_log es una función pura: dentro del presupuesto devuelve la cadena intacta (los builds normales no se ven afectados, las líneas con prefijo [STEP] se preservan); por encima del presupuesto descarta las líneas más antiguas y antepone un único marcador, plegando el recuento de cualquier marcador previo para que el re-acotado de cada tick acumule en lugar de apilarse. Que sea pura significa que es trivialmente testeable para la propiedad que de verdad importa — la cadena persistida está acotada — en lugar de para una propiedad vecina. Los tests ahora comprueban la salida de la función que el pipeline realmente llama: ≤ 10 001 líneas, < 8 MB, marcador presente, recuento que se acumula.
El residuo asumido
Queda una segunda pérdida que el arreglo no contabiliza del todo. Cuando el canal está lleno, try_send descarta la línea en silencio — bajo el aluvión de 2 M de líneas, unas 117 000 líneas se esfumaron antes de llegar al flusher. Atribuirlas con exactitud implicaría hacer pasar un contador atómico por las firmas de función de tres crates.
No lo hicimos. El marcador del límite ya anuncia «1,9 M de líneas descartadas para acotar la memoria», así que nada se presenta como silenciosamente completo, y el problema de severidad alta — la fila no acotada y su re-serialización en cada llamada a la API — queda cerrado. Contar los descartes por backpressure línea a línea es trabajo real para un número del que no depende ninguna decisión del usuario. Ese compromiso está escrito en el issue y en las notas de la versión, no dejado para que alguien lo redescubra. Un arreglo que se pasa de la raya es su propio tipo de deuda.
Qué llevarse de esto
Un límite vale lo que vale su posición en el flujo de datos. «¿Está acotado el valor?» no es la misma pregunta que «¿está acotado el valor que persistimos?» — y cuando un stream se ramifica hacia dos consumidores, una guarda en una rama no dice nada sobre la otra. Cuando añadas una cota, escribe el test contra el valor exacto que sale del sistema, no contra el proxy más cómodo. El proxy pasará. El sistema seguirá creciendo.