Skip to content

fix(docker): fail build when atlas download stalls instead of hanging#38

Open
tabedzki wants to merge 2 commits into
devfrom
fix/docker-atlas-build-required
Open

fix(docker): fail build when atlas download stalls instead of hanging#38
tabedzki wants to merge 2 commits into
devfrom
fix/docker-atlas-build-required

Conversation

@tabedzki

@tabedzki tabedzki commented Jul 8, 2026

Copy link
Copy Markdown
Collaborator

🤖 AI text below 🤖

Problem

The Docker build pre-downloads the mouse/rat atlases from the GIN server so the app starts instantly. When GIN stalls mid-transfer, docker build hangs indefinitelycheck_latest=False only skips the remote version check, not the actual data download, and the download socket has no timeout.

Change

Keep the requirement that atlases are baked into the image, but make a bad GIN server a bounded failure rather than an infinite hang:

  • Dockerfile — the pre-download now runs as timeout "${ATLAS_FETCH_TIMEOUT}" python /fetch_atlases.py (default 1200s) with no || true. A stall trips the timeout and fails the build; a download error propagates and fails the build. Either way, we never ship an image without atlases.
  • fetch_atlases.py (new) — idempotent fetch of the required atlases (skips ones already cached), non-zero exit if any is still missing. Shared by build and startup.
  • entrypoint.sh — runs the same script at startup as a cheap safety net. It's a no-op in the normal case (atlases baked in) and only re-fetches if a runtime volume mount shadows ~/.brainglobe/. REQUIRE_ATLASES=1 (default) makes a missing atlas a hard startup failure; set 0 to warn and boot anyway.

Verification

  • docker build -t pixelmap:build-test . succeeds; both atlases download during the build (allen_mouse_25um ~99 MB, whs_sd_rat_39um ~222 MB).
  • Running /fetch_atlases.py inside the built image reports both atlases already cached and exits 0 (startup check is a no-op as intended).

🤖 Generated with Claude Code

https://claude.ai/code/session_01EQUz7NQenGjdZVVRbk3a2Y

tabedzki added 2 commits July 8, 2026 06:38
The build-time atlas pre-download hit the GIN server directly and would
hang indefinitely when the server stalled mid-transfer, since check_latest=False
only skips the version check, not the data download.

Bound the download with `timeout` (ATLAS_FETCH_TIMEOUT, default 1200s) so a
stalled GIN server fails the build instead of hanging it, and let download
failures propagate so we never ship an image without atlases. Extract the
fetch logic into fetch_atlases.py, shared by the build and by a startup
re-verification in entrypoint.sh (a no-op in the normal case, but re-fetches
if a runtime volume mount shadows ~/.brainglobe/).

Assisted-by: ClaudeCode:claude-opus-4.8
…nced

`uv run` syncs the environment with the default dependency groups (including
dev) before executing. Since the image is built with `uv sync --no-dev`, the
entrypoint's `uv run` calls were re-installing dev-only packages (sphinx,
babel, ...) into the container at every startup. Pass --no-dev to match the
build so startup neither re-syncs nor pulls dev dependencies.

Assisted-by: ClaudeCode:claude-opus-4.8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant