fix: scope --add-host to the target's dependency closure#55
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Spawned by the audit (finding B1, #52). Design:
planning/changes/2026-07-14.02-add-host-closure-scope.md.--add-hostwas the one aggregate in the emit path built document-wide rather than scoped to the target's dependency closure.emit._planseeded hosts fromgraph.hostnames(services)— every service in the document — whileextra_hostswas layered per service inorder(the closure), andpod._add_host_flagsconflict-checks the two against each other.dns,dns_search,dns_opt,sysctls, secrets, and configs were all already closure-scoped. This makes--add-hostagree.Two symptoms
A service that never runs could veto a valid config:
→
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._planpasses only the closure's services tohostnames(). One line.hostnames()has exactly two callers and only the emit one changes.parsing.pykeeps calling it document-wide to shape-check every service'shostname/container_name/networksat the gate — scoping that too would silently stop rejecting a malformedhostnameon a service outside the closure.Verification
Four tests, two of which are deliberately guards against over-correcting: an in-closure
hostnamecolliding with an in-closureextra_hostsstill raisesconflicting host, and every closure member still contributes its name,hostname, and networkaliases.Review confirmed every service that actually joins the pod is still resolvable — including
service_healthyandservice_completed_successfullydependencies and transitive ones, sincestartup_orderdoesn't branch on condition. 553 tests at 100% coverage; integration suite green against real Podman 6.0.1.🤖 Generated with Claude Code