Deploy HiDream I1

Cause: Encoder count is model-specific and modern models pair a small CLIP with a large, easy-to-forget LLM/VL encoder: HiDream's QuadrupleCLIPLoader needs FOUR (incl. llama-3.1-8b fp8_scaled ~8.5GB); HunyuanVideo needs DUAL (clip_l + llava_llama3, +vision for i2v); Qwen-Image needs Qwen-2.5-VL-7B (~7GB fp8 to ~16GB bf16); Z-Image needs Qwen-3-4B (8GB). A 'not in list' error usually means you shipped N-1.

Fix: Ship the full encoder set for the exact model; the missing piece is almost always the large LLM/VL encoder, not the CLIP.

Cause: Unpinned by default: models pull from floating HF /resolve/main (branch HEAD), custom nodes are git-clone-latest (no SHA), Docker tags are reused, and only ~95% file-size is validated, not content hash. An upstream re-upload or newer node code silently changed bytes/behavior behind unchanged names.

Fix: Pin weights to a commit/revision, nodes to a SHA, images to a digest. Verify a pinned HF URL with `curl -sI -r 0-0 -A 'Mozilla/5.0' -L '<url>'` — MUST include -L (HF /resolve/ 302-redirects to a CDN; without -L you see 302 not 206).

Cause: The node was pinned to a commit predating when the required node class was added upstream. (The inverse also bites: a too-NEW pin can fail to import, forcing a rollback to an older release.)

Fix: Two-sided constraint: pin new enough that EVERY referenced node class is registered, but NOT so new it needs a ComfyUI newer than the baked image. Verify the pinned commit's NODE_CLASS_MAPPINGS registers all referenced classes AND imports cleanly against the deployed ComfyUI.

Cause: A reused mutable Docker tag means the container host serves an image it already cached under that tag and skips the re-pull after a rebuild (unless pull policy forces it or a differing digest is detected) — so it runs the stale image.

Fix: Push to a fresh tag or an immutable @sha256 digest. Treat 'not taking effect after rebuild' as a pull-cache symptom first.

Cause: A CRITICAL download fails (gated 401/403, bad URL, or too-small container disk), startup does exit 1, the container restarts, and the loop repeats — each restart clears the health/log server and its buffer so the UI shows nothing. Weights download to the CONTAINER disk (/app/ComfyUI/models); a network volume / persistentStorage does NOT relocate them, so an undersized container disk on a 30-60GB payload also loops.

Fix: Diagnose via the RunPod API (pod.runtime.uptimeInSeconds) + 9090/phase, not the wiped log buffer. Verify model URLs (curl -r 0-0 -A 'Mozilla/5.0' -L, expect 206), accept gated licenses, and size the CONTAINER disk for the full payload.

Cause: A custom-node requirements loop triggers heavy native/CMake from-source compiles (commonly llama-cpp-python and sam2) with no timeout and no wheel preference; one doomed compile or pip-resolver backtrack blocks the install indefinitely.

Fix: Wrap every pip call in `timeout ${PIP_TIMEOUT:-600}` and add `--prefer-binary`; pin known-source packages (e.g. xformers) to a wheel via a constraints file. (insightface is not the culprit here — it's only a model-dir name.)