Skip to content

fix: scope --add-host to the target's dependency closure#55

Merged
lesnik512 merged 1 commit into
mainfrom
fix/add-host-closure-scope
Jul 14, 2026
Merged

fix: scope --add-host to the target's dependency closure#55
lesnik512 merged 1 commit into
mainfrom
fix/add-host-closure-scope

Conversation

@lesnik512

Copy link
Copy Markdown
Member

Spawned by the audit (finding B1, #52). Design: planning/changes/2026-07-14.02-add-host-closure-scope.md.

--add-host was the one aggregate in the emit path built document-wide rather than scoped to the target's dependency closure. emit._plan seeded hosts from graph.hostnames(services) — every service in the document — while extra_hosts was layered per service in order (the closure), and pod._add_host_flags conflict-checks the two against each other. dns, dns_search, dns_opt, sysctls, secrets, and configs were all already closure-scoped. This makes --add-host agree.

Two symptoms

A service that never runs could veto a valid config:

services:
  app:   {image: i, extra_hosts: ["db:1.2.3.4"]}
  other: {image: i, hostname: db}          # not in app's closure; never started

UnsupportedComposeError: service 'app': conflicting host 'db' ('127.0.0.1' vs '1.2.3.4')

And the quieter one: a never-run service still got --add-host never_run:127.0.0.1, pointing its name at an address where nothing is listening — turning an honest name-resolution failure into a connection-refused.

The fix

emit._plan passes only the closure's services to hostnames(). One line.

hostnames() has exactly two callers and only the emit one changes. parsing.py keeps calling it document-wide to shape-check every service's hostname/container_name/networks at the gate — scoping that too would silently stop rejecting a malformed hostname on a service outside the closure.

Verification

Four tests, two of which are deliberately guards against over-correcting: an in-closure hostname colliding with an in-closure extra_hosts still raises conflicting host, and every closure member still contributes its name, hostname, and network aliases.

Review confirmed every service that actually joins the pod is still resolvable — including service_healthy and service_completed_successfully dependencies and transitive ones, since startup_order doesn't branch on condition. 553 tests at 100% coverage; integration suite green against real Podman 6.0.1.

🤖 Generated with Claude Code

@lesnik512 lesnik512 merged commit f7a3d45 into main Jul 14, 2026
7 checks passed
@lesnik512 lesnik512 deleted the fix/add-host-closure-scope branch July 14, 2026 13:44
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