kevinveenbirkenbachandClaude Opus 5 549d272884 refactor(lookup): keep one resolver for a variable that may still be a template ...

Seven lookups read application_id out of the play's variables and every one of
them has to template it, because sys-stk-full defines application_id from
sys_stk_full_application_id and a dict read returns that unrendered. They did
it in five spellings: a public resolve_var, two byte-identical private copies,
and inline variants. Nothing named the rule, so it survived as folklore, and a
lookup written without knowing it took down three jobs of one run.

resolve_var now lives in utils/templating, which is where the six lookups that
import it can reach it without pulling in a networking module for a concern
that is not networking. utils/networks/lookup_context re-exports it under the
alias form, so its own importers are untouched and autodoc still resolves one
target. The two private copies go, and so does the fourth copy this branch
added to webserver_resource a few commits ago.

The private copies guarded value is not None and the public one did not. The
canonical keeps the guard: it is narrower than every live caller, each of
which passes a defaulted value, so no existing call can reach the branch.

The helper had no test at all. Its six behaviours are characterised first,
including that a templar raising on an undefined variable leaves the value
alone rather than failing the play, which is what the suppression is for.

Four inline copies stay. compose_volumes lets a template error propagate where
this suppresses it, and mcp_servers only templates a str containing a template
marker. Folding those in would change behaviour, which is not a refactor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-28 11:30:54 +02:00

..

__init__.py

…

test_ansible.py

…

test_jinja.py

…

test_vars.py

refactor(lookup): keep one resolver for a variable that may still be a template

2026-09-28 11:30:54 +02:00