# Locality of reference: override semantics for ansible 1.9.2 are wrong (IMHO)

**URL:** <https://forum.ansible.com/t/locality-of-reference-override-semantics-for-ansible-1-9-2-are-wrong-imho/19204>\
**Category:** Ansible Project\
**Created:** [September 8, 2015, 9:00am UTC](https://forum.ansible.com/t/locality-of-reference-override-semantics-for-ansible-1-9-2-are-wrong-imho/19204 "2015-09-08T09:00:50Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jan.grant](https://avatars.discourse-cdn.com/v4/letter/j/7ab992/32.png) [@jan.grant](https://forum.ansible.com/u/jan.grant)\
**Post date:** [September 8, 2015, 9:00am UTC](https://forum.ansible.com/t/locality-of-reference-override-semantics-for-ansible-1-9-2-are-wrong-imho/19204/1 "2015-09-08T09:00:50Z")

</div>

Just came across a really hard bug to track down. The code in question looked, essentially, like this:

[[[

- include: some\_file.yml  
vars:  
x: 1  
]]]

The problem here was that some\_file.yml was not being invoked with x set to 1. The reason for this was that another included playbook had done the following:

[[[

- set\_fact:  
x: 2  
]]]

As you might imagine, this behaviour leads to bugs that are almost impossible to track down: one cannot examine an include and know for certain the variables that will be passed into the included task.

I’ve raised a bug on this but I’d appreciate feedback about whether this really is broken by accident: I find it hard to believe that anyone’s depending on the current behaviour.

[https://github.com/ansible/ansible/issues/12277](https://github.com/ansible/ansible/issues/12277)

Cheers,  
jan