fix(docker): retry the HuggingFace prewarm fetch instead of failing the build - #338

cdeust · 2026-08-02T13:41:39Z

Le défaut

docker/Dockerfile et .devcontainer/Dockerfile pré-cachent le modèle d'embedding avec un fetch réseau single-shot. Un blip transitoire de huggingface.co fait donc échouer le build entier.

Ce n'est pas hypothétique — c'est arrivé aujourd'hui :

#17 73.06 OSError: We couldn't connect to 'https://huggingface.co' to load the files,
          and couldn't find them in the cached files.
ERROR: failed to build: ... docker/Dockerfile:97

CI run 30749502167, sur la PR #337, dont la diff ne touchait ni ce Dockerfile ni aucune de ses dépendances. Le même job passait sur le commit parent, et un re-run sans changement de code est repassé vert. C'est le fetch qui décidait de l'issue du build, pas le contenu de la PR.

Le correctif

ci.yml avait déjà résolu ce problème à quatre endroits (5 tentatives, backoff attempt*10s, échec bruyant). Les Dockerfiles sont les seuls chemins qui ne l'avaient jamais reçu. Ce commit y porte l'idiome à l'identique, constantes comprises, avec # source: pointant vers ci.yml.

Le prewarm FlashRank du devcontainer reçoit le même traitement. L'échec bruyant après épuisement des tentatives y est délibéré : une image silencieusement non-préchauffée, c'est l'incident du 2026-07-11 (re-ranker absent en silence, 6 benchmarks invalidés) reproduit une couche plus haut.

Choix explicites

Pas de cache mount BuildKit. Le stage runtime fait COPY --from=builder /root/.cache/huggingface — un cache mount ne fait pas partie du layer, l'image sortirait sans modèle.
scripts/setup.sh volontairement non modifié. Il fait le même fetch, mais dégrade déjà en « will download on first use » au lieu d'échouer. Y ajouter des retries n'achèterait aucune correction et coûterait jusqu'à 100 s d'attente silencieuse dans un installeur interactif.

Vérification

Les corps de RUN, joints comme Docker joint les continuations (sans newline), passent sh -n.
Les trois charges python -c compilent (compile(..., "exec")).
Le helper retry retourne 0 sur le chemin succès et propage un code non nul après épuisement — les deux chemins exécutés.
Flake confirmé empiriquement : re-run du job en échec, sans changement de code → vert.

🤖 Generated with Claude Code

…he build Both image builds pre-cache the embedding model with a single-shot network fetch. A transient huggingface.co blip therefore fails the build outright: CI run 30749502167 (PR #337, 2026-08-02) died on "We couldn't connect to 'https://huggingface.co'" after 73s, on a commit whose diff touched neither Dockerfile nor any of their dependencies. Re-running the same job with no code change passed — the fetch, not the change, decided the outcome. ci.yml already solved this in four places (attempts + backoff + loud failure). The Dockerfiles were the paths that never got it. This mirrors that idiom verbatim, constants included, and cites it as the source. The devcontainer image gets the same treatment for its FlashRank prewarm: failing loudly after the retries is deliberate there, since a silently unprewarmed image reproduces the 2026-07-11 silent-reranker incident one layer up. No BuildKit cache mount: the runtime stage COPYs the HF cache out of the builder layer, and a cache mount is not part of the layer. scripts/setup.sh performs the same fetch but is deliberately left alone — it already degrades to "will download on first use" instead of failing, so retries would buy no correctness and cost up to 100s of silent wait in an interactive installer. Verified: both RUN bodies joined the way Docker joins continuations parse under `sh -n`; all three `python -c` payloads compile; the retry helper returns 0 on the success path and propagates non-zero after exhausting attempts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cdeust merged commit 2e87f99 into main Aug 2, 2026
19 checks passed

cdeust deleted the fix/harden-hf-prewarm-fetch branch August 2, 2026 13:59

Navigation Menu

fix(docker): retry the HuggingFace prewarm fetch instead of failing the build - #338