flowerysong

This is not a bug. The value of `status` is consistent with the documented variable precedence in https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#ansible-variable-precedence "set_facts / registered vars" is 19th on the list, "task vars" is...

The module returns detailed information about all of the services, not just a simple list. ```yaml - service: state: stopped name: ntpd.service when: ansible_facts['services']['ntpd.service']['status'] | default('not-found') != 'not-found' ```

Role argument validation is just validation and cannot change the content of variables, This is unlikely to change since it would introduce even more complexity to the already complex variable...

The only code path I see that could plausibly result in this is https://github.com/ansible/ansible/blob/8ad68f12eec3435ef6bb3564d6465717eca95ecf/lib/ansible/modules/cron.py#L327-L328 Does changing that line to `self.module.fail_json(msg=err, stdout=out, rc=rc)` provide any useful information?

This change is not correct. `msg` is a returned value from this module that not all modules return, so it should be documented. `changed` is something that is common to...

You can also move the lookup so that it's part of the `until` condition, which *does* get evaluated each time. ```yaml - hosts: localhost vars: new_value: "{{ lookup('ansible.builtin.file', '/var/tmp/foo.txt') }}"...

#82425 partially fixes this, but requires that you pass an empty term in order for things to work as expected: `query('ansible.builtin.sequence', '', start=0, count=2)`. While this should probably be fully...

This is an interesting workaround, but in my opinion a better solution is to turn off top-level fact injection (https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars).

> Are you aware of potential side effects of setting `ANSIBLE_INJECT_FACT_VARS` besides having to alway add `ansible_facts` before all newly added facts? No, that's the only effect. As I understand...

This is not a bug, it is the expected behaviour (though the documentation could be slightly improved, since this is only mentioned in https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_tags.html#special-tags-always-and-never and not in the role argument...