Using `notify` with an `include` statement silently fails

Archives Ansible Project
1

Hi!

I've recently been bitten by this unintuitive behaviour. For example, in
a task like this:

- include: foo.yml
  notify:
    - test handler

the 'test handler' is (silently) not being run.

Even adding 'changed_when: true', i.e. changing the above to:

- include: foo.yml
  changed_when: true
  notify:
    - test handler

doesn't help.

The whole minimal reproducing example is here:
https://github.com/tjanez/ansible-using_notify_with_include_bug

My questions are the following:
1) Is this the expected/intended behaviour?
2) If yes, should we warn the user that using notify with an include
statement will not work?

Thanks and best regards,
Tadej

2

It’s working-as-designed behavior with regard to not being able to do what you have, but not perfect - it should report on the error condition.

There’s currently no “notify” logic like you have attached to an include, and what is happening is the “include” “object” doesn’t really have validation associated with it to the level that it should.

I’m not sure it should yell at you, as IMHO this should define variables:

  • include: foo.yml x=2

is a thing

as such

  • include: foo.yml
    x: 2

should be a thing also.

As such, notify would just be another word.

Now if variables aren’t taking in that case, that’s a bug.

This is tricky, I know - but basically my advice in the past is, if you see syntax in the docs, it’s syntax. But if you make something up, you might just be passing data to something :slight_smile:

I hope this is understandable. It’s somewhat the nature of it being a data format.

Now, if you want to “tag” every task in an include with a handler, that may be the first time I’ve seen that. It seems a little curious. Are there specific tasks you might want to affix a handler to instead?

3

Hi!

First, thanks for a quick answer!

It’s working-as-designed behavior with regard to not being able to do what you have, but not perfect - it should report on the error condition.

Ok, I see. Thanks for clearing it up!

There’s currently no “notify” logic like you have attached to an include, and what is happening is the “include” “object” doesn’t really have validation associated with it to the level that it should.

I’m not sure it should yell at you, as IMHO this should define variables:

  • include: foo.yml x=2

is a thing

as such

  • include: foo.yml
    x: 2

should be a thing also.

Yes, agreed. I use often use such variable passing (:slight_smile: with include statements, since it is more readable when variables have longer values.

As such, notify would just be another word.

Aha, I see now. It’s hard to say, what should be the proper behaviour. Would it maybe make sense to warn the user that he is passing a variable named ‘notify’ to the include statement rather that notifying the desired handler?

Now if variables aren’t taking in that case, that’s a bug.

No, that’s working perfectly.

This is tricky, I know - but basically my advice in the past is, if you see syntax in the docs, it’s syntax. But if you make something up, you might just be passing data to something :slight_smile:

I hope this is understandable. It’s somewhat the nature of it being a data format.

Not intuitive at first, but obvious now :).

Now, if you want to “tag” every task in an include with a handler, that may be the first time I’ve seen that. It seems a little curious. Are there specific tasks you might want to affix a handler to instead?

What happened in my concrete case was that the last task in a series of tasks deploying some web server application was to include some common YAML file and that I have a habit of adding notify statement to the last task in a series. So, nothing special :).

Thanks and regards,
Tadej