ansible-core 2.19 Templating Changes: Fix Broken Conditionals & Jinja Errors

By Luca Berton · Published 2024-01-01 · Category: installation

Deep dive into ansible-core 2.19 templating changes. Fix broken conditionals, multi-pass templating errors, Jinja2 order of operations bugs, dictionary-as-conditional YAML traps, and expression syntax errors with before/after playbook examples.

ansible-core 2.19 includes a complete overhaul of the templating engine and introduces Data Tagging. This changes how Ansible evaluates conditionals, templates, and expressions — and it will break playbooks that relied on loose truthy evaluation.

This article covers every templating change with before/after code examples so you can fix your playbooks fast.

The Big Picture

The templating overhaul has three effects: Broken conditionals are now errors — when and assert must return actual booleans Multi-pass templating is removed — no more {{ }} inside expressions Expression syntax errors are caught — previously silent bugs now surface

Broken Conditionals: The Full List

1. Implicit Boolean Conversion

The most common issue. Variables used directly as conditionals return their value (a string, dict, list) — not a boolean.

2. Registered Variable Checks

3. Quoted Expressions in assert

4. Dictionary as Conditional (YAML Trap)

This one is subtle. In YAML, key: value (colon + space) creates a mapping, not a string.

5. Jinja2 Operator Precedence

The ~ concatenation operator has lower precedence than tests like contains.

6. Expression Syntax Errors

Multi-Pass Templating Removal

Template Delimiters in Expressions

Nested Template Strings

Template in Arithmetic

Dynamic when Clauses

Bulk Fix Script

Use this script to find and categorize issues in your codebase:

Migration Strategy

Phase 1: Discover (Week 1)

Phase 2: Fix (Weeks 2-3)

Fix in priority order: Production playbooks — anything in your CI/CD pipeline Shared roles — used by multiple teams One-off playbooks — ad hoc automation

Phase 3: Validate (Week 4)

Phase 4: Upgrade Production

Common Fix Patterns Reference

| Before (2.18) | After (2.19) | Issue | |---|---|---| | when: my_var | when: my_var \| length > 0 | Truthy string | | when: result.stdout | when: result.stdout \| length > 0 | Truthy string | | when: my_list | when: my_list \| length > 0 | Truthy list | | when: my_dict | when: my_dict \| length > 0 | Truthy dict | | when: "{{ var }}" | when: var | Template in expr | | that: '...' (with and '...') | Remove inner quotes | Quoted sub-expr | | that: x == "a: b" | that: 'x == "a: b"' | YAML colon trap | | x is contains "a" ~ "b" | x is contains("a" ~ "b") | Operator precedence |

FAQ

What is the ALLOW_BROKEN_CONDITIONALS setting?

A temporary configuration option in ansible-core 2.19 that changes broken conditional errors to warnings. Set allow_broken_conditionals = true in ansible.cfg under [defaults] or export ANSIBLE_ALLOW_BROKEN_CONDITIONALS=true. Use it during migration only — it will be removed in a future release.

Why did ansible-core 2.19 change the templating engine?

The overhaul introduces Data Tagging, which tracks metadata about template data for improved security (prevents untrusted template execution), performance, and user experience (catches real bugs that were silently ignored for years).

How do I fix "Conditional result was X of type str"?

Add an explicit boolean test. If checking a string, use | length > 0 or is truthy. If checking existence, use is defined. If comparing values, use == or !=. The key rule: every when and assert expression must evaluate to True or False, not a truthy value.

Will these templating changes be reverted?

No. The broken conditional enforcement and multi-pass templating removal are permanent security and correctness improvements. The ALLOW_BROKEN_CONDITIONALS option is a temporary migration aid only.

Conclusion

ansible-core 2.19's templating changes are the most significant in Ansible's history. They catch real bugs and prevent security issues — but they require updating existing playbooks. Use the audit script, fix in phases, and test thoroughly before upgrading production.

Related ArticlesAnsible 12 Upgrade GuideAnsible Conditionals: when & assertAnsible Jinja2 Filters Complete ReferenceAnsible block/rescue/always Error Handling

Category: installation

Browse all Ansible tutorials · AnsiblePilot Home