I just got bitten by this:

- hosts: examplehost
  tasks:
  - name: "a task"
    shell: "echo this is just an example it applies to any action"
    sudo: "yes"
    sudo_user: "{{ userr }}" # oops, typo'd variable name
  vars:
    user: "myuser"

Which produces:

TASK: [a task] ****************************************************************
failed: [examplehost] => {"failed": true, "parsed": false}
invalid output was: sudo: unknown user: {{
sudo: unable to initialize policy plugin

I can submit another ticket, or I can just leave this as a note on this ticket.

And again with the odd {# ... #} case:

TASK: [app | config | Create the basic deploy target directories] *************
failed: [app01] => (item={# app_path #}) => {"failed": true, "item": "{# app_path #}", "parsed": false}

- name: "config | Create the basic deploy target directories"
  file:
    name: "{{ item }}"
    state: "directory"
    owner: "{{ app_user_username }}"
    group: "{{ app_user_username }}"
  with_items:
  - "{{ app_path }}"
  - "{{ app_path_releases }}"
  # ...

This looks like a bug down the lazy evaluation path to me.

The "{{ foo }}" becoming "{# foo #}" is a result of the "anti-new parameter injection" security checking stuff coming in which should not come into play here. I would expect it to remain "{{ foo }}" and result in an undefined variable error.

@damncabbage is this only happening with variables that are undefined, or are you seeing this with all variables?

Only typo'd / undefined variables.

(In the last example, app_path was a typo of app_path_root. app_path_releases was defined and worked fine.)

Great, just wanted to make sure, I'm looking into this now. Thanks!

@damncabbage I've created the above patch, if you'd like to test it out. Using your first example, the following output is the result:

PLAY [localhost] ************************************************************** 
TASK: [things with_items] ***************************************************** 
fatal: [127.0.0.1] => undefined variable in items: 'should_explode' is undefined
FATAL: all hosts have already failed -- aborting

Tested the patch; it explodes as expected. Thanks. 😃

My test case (simpler than the initial setup):

- hosts: localhost
  tasks:
  - debug:
      var: "{{ item }}"
    with_items: a_list
  vars:
    a_list:
    - "{{ foo }}"
    - "{{ foob }}"
    foo: "Hello"

I do agree with @redbaron; please instead consider:

  import subprocess
  import contextlib
+ import jinja2.exceptions

  from vault import VaultLib

              # if not already a list, get ready to evaluate with Jinja2
              # not sure why the "/" is in above code :)
              try:
-                 new_terms = template.template(basedir, "{{ %s }}" % terms, inject)
+                 new_terms = template.template(basedir, terms, inject, convert_bare=True, fail_on_undefined=C.DEFAULT_UNDEFINED_VAR_BEHAVIOR)
                  if isinstance(new_terms, basestring) and "{{" in new_terms:
                      pass
                  else:
                      terms = new_terms
+             except jinja2.exceptions.UndefinedError, e:
+                 raise errors.AnsibleUndefinedVariable('undefined variable in items: %s' % e)
              except:
                  pass

(Is it standard practice with this project to also add a case to the automated test suite?)

Feel free to send a PR for that so you get credit, the way I did it was admittedly not pythonic.

Done; thank you.

Closing This Ticket

Hi!

We believe the above commit should resolve this problem for you. This will also be included in the next major release.

If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

• https://groups.google.com/forum/#!forum/ansible-project - for user questions, tips, and tricks
• https://groups.google.com/forum/#!forum/ansible-devel - for strategy, future planning, and questions about writing code

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

It was reverted in 97408fe

Can you explain - why? Ansible ignores undefined variables again.