Skip to content

Readiness names the daemon, not a Go template error - #237

Merged
thedancingdeveloper merged 1 commit into
mainfrom
fix/docker-readiness-names-the-daemon
Aug 8, 2026
Merged

Readiness names the daemon, not a Go template error#237
thedancingdeveloper merged 1 commit into
mainfrom
fix/docker-readiness-names-the-daemon

Conversation

@thedancingdeveloper

Copy link
Copy Markdown
Contributor

Found while building the deployment image, which is a host with the Docker CLI installed and no daemon reachable.

DockerEnvironmentFactory.check() ran docker info --format {{.ServerVersion}} and reported the last line of stderr. With a format string an unreachable daemon still renders a mostly-nil Info struct, so the last line is a Go template error about indirection through nil pointer to embedded struct field Info, and the line that says Cannot connect to the Docker daemon sits above it.

So /api/readiness and doctor would have told an operator that reflection was stopping the fleet. That is a message naming the wrong component — the failure class this repository has paid for repeatedly.

docker info is now asked with no format, the exit code decides readiness, and the reported line is the one a person can act on. A daemon that answers reports its parsed Server Version:.

Two regression tests pin it, including that empty stderr still names the component instead of going blank.

Failing run: https://github.com/TheDancingDeveloper-org/agent-harness/actions/runs/31245089056

Building the deployment image found this: the image has the Docker CLI and no
daemon, and `check()` reported

    template: :1:2: executing "" at <.ServerVersion>: reflect: indirection
    through nil pointer to embedded struct field Info

Asked with `--format`, an unreachable daemon still makes the CLI render a
mostly-nil `Info` struct, so the template error is the LAST line of stderr and
"Cannot connect to the Docker daemon" is above it. `check()` took the last
line, so `/api/readiness` and `doctor` would have blamed reflection for a
stopped service — a message naming the wrong component, which is the failure
this repository keeps paying for.

`docker info` is now asked without a format, the exit code decides, and the
reported line is the one a person can act on: template noise is a consequence
of the daemon being absent, never the reason. A daemon that answers reports
its parsed `Server Version:`.

Found by deploying, not by reading. The dev host has the same CLI-without-
daemon shape and never surfaced it, because the failing assertion only fires
where `docker info` produces the template error rather than a plain refusal.
@thedancingdeveloper
thedancingdeveloper merged commit e544291 into main Aug 8, 2026
3 checks passed
@thedancingdeveloper
thedancingdeveloper deleted the fix/docker-readiness-names-the-daemon branch August 8, 2026 07:48
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