container image starts with missing runtime dependencies and wrong Python path #21

New issue

Closed

opened 2026-07-02 05:35:59 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-02 05:35:59 +00:00

Member

Problem

The current container image for agent-proxy does not boot successfully after build.

What happened

After building agent-proxy-local:latest and letting the infra ansible role launch it, the container entered a restart loop.

The first failure was:

ModuleNotFoundError: No module named 'fastapi'

A local experiment showed why:

uv sync --extra dev installs into /app/.venv
the container entrypoint still runs python -m app.main
/app/.venv/bin is not on PATH

After adding /app/.venv/bin to PATH in a temporary local rebuild, the next failure was:

ModuleNotFoundError: No module named 'pydantic_settings'

That points to missing runtime dependencies as well, not only the PATH issue.

Repro

Build the current repo Dockerfile.
Run the container with the documented command path.
Observe the restart loop and missing-module tracebacks in docker logs.

Expected

The built image should boot the FastAPI app and serve the health endpoint.

Actual

The image restarts immediately because the runtime environment is incomplete.

Likely fixes

Move actual app runtime dependencies out of optional-dependencies.dev and into normal project dependencies.
Make the Dockerfile run inside the uv-managed environment, or install into the system interpreter intentionally.
Validate the image with a boot smoke test that hits the health endpoint.

Impact

Infra can converge the container definition, but the service never becomes healthy because the image itself is broken.

## Problem The current container image for `agent-proxy` does not boot successfully after build. ## What happened After building `agent-proxy-local:latest` and letting the infra ansible role launch it, the container entered a restart loop. The first failure was: * `ModuleNotFoundError: No module named 'fastapi'` A local experiment showed why: * `uv sync --extra dev` installs into `/app/.venv` * the container entrypoint still runs `python -m app.main` * `/app/.venv/bin` is not on `PATH` After adding `/app/.venv/bin` to `PATH` in a temporary local rebuild, the next failure was: * `ModuleNotFoundError: No module named 'pydantic_settings'` That points to missing runtime dependencies as well, not only the PATH issue. ## Repro 1. Build the current repo Dockerfile. 2. Run the container with the documented command path. 3. Observe the restart loop and missing-module tracebacks in `docker logs`. ## Expected The built image should boot the FastAPI app and serve the health endpoint. ## Actual The image restarts immediately because the runtime environment is incomplete. ## Likely fixes * Move actual app runtime dependencies out of `optional-dependencies.dev` and into normal project dependencies. * Make the Dockerfile run inside the uv-managed environment, or install into the system interpreter intentionally. * Validate the image with a boot smoke test that hits the health endpoint. ## Impact Infra can converge the container definition, but the service never becomes healthy because the image itself is broken.

coilyco-ops commented

2026-07-02 05:38:06 +00:00

Author

Member

🔒 Reserved by ward agent --driver goose — container engineer-goose-agent-proxy-21 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T05:38:04Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Goose, via ward agent

🔒 Reserved by `ward agent --driver goose` — container `engineer-goose-agent-proxy-21` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T05:38:04Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Goose, via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 05:45:57 +00:00

Fix container image startup issues

coilysiren commented

2026-07-02 08:19:22 +00:00

Owner

Fixed on main by the work that closed #22 (the same crash - malformed [project.dependencies] table plus undeclared pydantic-settings/prometheus-client, and the venv PATH you diagnosed here). #22 rewrote deps as a PEP 621 array, regenerated the lock, made the Dockerfile uv sync --frozen --no-dev runtime-only, and restored the real OpenAI surface a scaffold commit had stubbed. The goose run reserved here on 2026-07-02T05:38Z did not land (reservation went stale at 07:38Z) and this ticket duplicates #22, so closing as fixed.

Fixed on `main` by the work that closed #22 (the same crash - malformed `[project.dependencies]` table plus undeclared `pydantic-settings`/`prometheus-client`, and the venv `PATH` you diagnosed here). #22 rewrote deps as a PEP 621 array, regenerated the lock, made the Dockerfile `uv sync --frozen --no-dev` runtime-only, and restored the real OpenAI surface a scaffold commit had stubbed. The goose run reserved here on 2026-07-02T05:38Z did not land (reservation went stale at 07:38Z) and this ticket duplicates #22, so closing as fixed.

coilysiren closed this issue

2026-07-02 08:19:23 +00:00