# failed\_when sequence logic

**URL:** <https://forum.ansible.com/t/failed-when-sequence-logic/18655>\
**Category:** Ansible Project\
**Created:** [July 1, 2015, 6:31pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655 "2015-07-01T18:31:14Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tom\_Paine1](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@Tom\_Paine1](https://forum.ansible.com/u/Tom_Paine1)\
**Post date:** [July 1, 2015, 6:31pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/1 "2015-07-01T18:31:14Z")

</div>

Having trouble understanding if there’s a bug in failed\_when, or my understanding is incorrect -

a _false_ and a _true_ are OR’ing in a YAML sequence to _false_:

Fails (failed when evals to true):

`

failed\_when:

- ‘“300 OK” not in command\_result.stderr’

`

Passes (failed when evals to false):

`

failed\_when:

- command\_result.rc != 0

`

Both together pass (failed when evals to false):

`

failed\_when:

- ‘“300 OK” not in command\_result.stderr’
- command\_result.rc != 0

`

Spent an hour going back a forth trying to find a syntax error. failed\_when passes the task when it evaluates to false, I’ve seen a post from Michael DeHaan saying sequences are treated like ORs.

What am I not seeing?

---

<div class="post-metadata">

**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\
**Post date:** [July 1, 2015, 6:45pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/2 "2015-07-01T18:45:17Z")

</div>

When you give when, changed\_when or failed\_when a list, the items are ANDed, not ORed.

---

<div class="post-metadata">

**Author:** ![Tom\_Paine1](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@Tom\_Paine1](https://forum.ansible.com/u/Tom_Paine1)\
**Post date:** [July 1, 2015, 6:46pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/3 "2015-07-01T18:46:55Z")

</div>

Simplified, I’ve tried:

failed\_when:

- true
- false

evals to false. Surely a bug?

This is the post where sequences are said to evaluate as OR  
[https://groups.google.com/d/msg/ansible-project/cIaQTmY3ZLE/c5w8rlmdHWIJ](https://groups.google.com/d/msg/ansible-project/cIaQTmY3ZLE/c5w8rlmdHWIJ)

---

<div class="post-metadata">

**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\
**Post date:** [July 1, 2015, 6:50pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/4 "2015-07-01T18:50:14Z")

</div>

No, pretty sure that is correct, here is the output from the operation of ‘True and False’ in Python:

In [1]: True and False  
Out[1]: False

Like I said, they are ANDed not ORed.

If you want to use an or, you are going to have to write it out such as:

failed\_when: true or false

---

<div class="post-metadata">

**Author:** ![Tom\_Paine1](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@Tom\_Paine1](https://forum.ansible.com/u/Tom_Paine1)\
**Post date:** [July 1, 2015, 7:02pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/5 "2015-07-01T19:02:43Z")

</div>

Not convinced it’s good syntax, for a failure\_when I’d expect an OR.

But ok.

My issue is that I now I want to OR a bunch of multiline statements:

`

failed\_when:

- 

> 

“long string with characters that need escaping”  
over many $%^&\*  
lines

- 

> 

and another  
long  
line

- etc
- etc

`

How to OR over multiline sequences?

---

<div class="post-metadata">

**Author:** ![Tom\_Paine1](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@Tom\_Paine1](https://forum.ansible.com/u/Tom_Paine1)\
**Post date:** [July 1, 2015, 7:20pm UTC](https://forum.ansible.com/t/failed-when-sequence-logic/18655/6 "2015-07-01T19:20:24Z")

</div>

Ok, got it.

`  
failed\_when: \>  
“foo  
bar”  
not in x or  
“baz  
bar”  
not in y

`

etc. Thanks for the help Matt. Hottest July day on record with no air-con wasn’t helping either 🙂
