https://jayreddinjr-jr-odysseus-hf.hf.space/static/js/cookbookProgressSignal.js

1// static/js/cookbookProgressSignal.js
2/**
3 * Liveness signal for a running cookbook download/install. The watchdog treats a
4 * task as stalled when this signal stays unchanged for too long, so it must move
5 * whenever the task is genuinely making progress.
6 *
7 * During a model DOWNLOAD the honest signal is the downloaded-byte counter
8 * ("1.81G" from "1.81G/2.49G"): it climbs while transferring and freezes when
9 * stuck — and unlike a % bar or speed/ETA it doesn't keep animating on a frozen
10 * frame. That path is kept exactly as-is.
11 *
12 * But a dependency install (e.g. vllm) spends long stretches with NO byte
13 * counter — pip dependency resolution and the native CUDA build/compile. A
14 * byte-only signal freezes there, so the watchdog falsely declares the install
15 * stale and restarts it mid-build, looping forever (#1568). When there's no byte
16 * counter, fall back to a fingerprint of the output tail: resolver/compile lines
17 * keep changing while the process is alive, and only a truly hung process leaves
18 * the tail frozen.
19 *
20 * Pure (string in, string out) so it's unit-testable; cookbookRunning.js pulls
21 * in browser-only modules and can't load under node.
22 */
23export function computeProgressSignal(bytes, dlAgg, lastPct, snapshot) {
24  if (bytes) return bytes;
25  const base = dlAgg != null ? String(dlAgg) : (lastPct || '0');
26  // No byte counter → use the output tail so a build/resolve phase that emits new
27  // lines counts as progress instead of a false stall (#1568).
28  return base + '|' + String(snapshot || '').slice(-300);
29}