Falling back to Ansible unique filter as Jinja2 one failed: '<variable>' is undefined

[Noksa]

Summary

Ansible-lint complains about undefined variable as warning

Issue Type

• Bug Report

OS / ENVIRONMENT

ansible-lint --version
ansible-lint 6.14.3 using ansible 2.14.3

• ansible installation method: pip
• ansible-lint installation method: pip

STEPS TO REPRODUCE

Create playbook debug.yml

- name: Debug
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Set fact
      ansible.builtin.set_fact:
        qq: ["qq", "ww"]
    - name: Print it
      ansible.builtin.debug:
        msg: "{{ qq | unique }}"

Run ansible-lint

ansible-lint debug.yml

Desired Behavior

Output should be like that

❯ debug (master) ✘ ansible-lint debug.yml

Passed with production profile: 0 failure(s), 0 warning(s) on 1 files.

Actual Behavior

I see warning in output

❯ debug (master) ✘ ansible-lint debug.yml                    
[WARNING]: Falling back to Ansible unique filter as Jinja2 one failed: 'qq' is undefined

Passed with production profile: 0 failure(s), 0 warning(s) on 1 files.

I tried to use unique | list and unique | flatten(1) - didn't help.

Is it possible to avoid such warning? I have 10+ places with unique filter and it is annoying a bit.

[chriscroome]

This is triggered even when a fully qualified name is used for the filter:

- name: Set a fact
  ansible.builtin.set_fact:
    list3: "{{ list1 + list2 | ansible.builtin.unique }}"

The result being:

[WARNING]: Falling back to Ansible unique filter as Jinja2 one failed: 'list2' is undefined

I'd understand it more if unique was used unqualified as it is Jinja2 filter.

It's a shame the Ansible filter wasn't called something different, for example uniq, to avoid this 🤷‍♂️ .

[ssbarnea]

One of the problems about this one is that this warning is generated by ansible-core and directly sent to stdout, bypassing us completely.

That is not a standard python logging or warnings implementation, it is just a plain print, so capturing it is very tricky. I have being doing some work/research for redirecting stdout and stderr during run but it proved to cause problems so far, especially with our pytest unitests.

We will sort it, but it might take few more weeks, for now you can ignore the message.

[chriscroome]

Thanks @ssbarnea, it sounds like perhaps it should be raised upstream?

[cidrblock]

Looks like that filter has some history to it, and came out before the jinja filter. It's error is here https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/filter/mathstuff.py#L68 which was implemted here https://github.com/ansible/ansible/pull/45637/files...

It's unfortunate that the warnings ansible emits don't have an ID to them, b/c we end up having to string match everywhere ugh

[chriscroome]

Thanks @cidrblock, I'm afraid my Python isn't upto much… am I to understand that using ansible.builtin.unique result in Ansible trying to use the Jinja2 filter and then falling back to the Ansible one?!

Would it make sense to propose that at some future date the behaviour is changed so that using unique always results in the Jinja2 filter and using ansible.builtin.unique always results in the Ansible filter?

[bcoca]

@chriscroome

It's a shame the Ansible filter wasn't called something different, for example uniq, to avoid this man_shrugging .

Hard to do since the Ansible filter predates the Jinja one. We are looking for a way in core to add a 'Jinja namespace' to allow explicit use of one of the other.

In general the 'matching name filters' should deffer to the Jinja one once present, in some cases we make the decision based on input as the acceptable options are not always the same.

In this case we try the Jinja one first, which handles less cases than the Ansible one, when that fails we use the one in core and emit that warning.

[chriscroome]

the Ansible filter predates the Jinja one

Thanks @bcoca, I wasn't aware of that when I posted the above. Adding a 'Jinja namespace' sounds like a very sensible way forward for differentiating the types of filters 👍