default task on error not running when task fail to evaluate input

[Michal Gershenzon]

To reproduce run the next workflow.
task `my_on_error`does not get executed even though task `bad_input_will_fail_task` failed to run.

---
version: "2.0"
def_on_error_not_running:

  task-defaults:
    on-error:
      - my_on_error

  tasks:
    first:
      action: std.noop
      on-success:
        - bad_input_will_fail_task

    bad_input_will_fail_task:
      action: std.http
      input:
        url: <% $.url %>

    my_on_error:
      action: std.noop

[Renat Akhmerov (rakhmerov)]

According the current semantics of "on-error" clause this isn't a bug. "on-error" handles only errors of actions, not errors related YAML syntax, expression evaluation, data flow logic etc. The situation in your example I think shows that there's a problem with the workflow definition (an attempt to use an invalid context variable), it doesn't make sense to handle it with "on-error".

[Renat Akhmerov (rakhmerov)]

I believe though that this is not documented well.

[Michal Gershenzon (michal-gershenzon)]

If you don't want to call this a bug, we can make a blueprint out of this.

I want to clarify that my example is not a full use-case. The problem that I want to solve is this - a workflow can have a task that publish things after a std.http action and then another tasks that takes some of that published value and pass it as input, if the input validation fails, I still want some tasks to run and I want this to be in a way that will not be over complicated for the user.

I am open to other possibilities, maybe a safe way to validate inputs?
Maybe we should consider another section for what to do in such errors?

Another use-case I thought about: Imagine a user has a cron trigger running a workflow making sure some system is up, and if not sending an email. All works well, but then one of the external systems the workflow was talking to, returned a response in a different format (maybe some of the fields change from uppercase to lowercase), not does the workflow always fails from this point, but also the user will never get any emails about it and will think all is well, even if the system that the user wanted to monitor is down.

I would love to hear your thoughts on how we should continue and if you agree that we have valid use-cases here.

[Renat Akhmerov (rakhmerov)]

Yes, please make a BP, that would be right.

[Michal Gershenzon (michal-gershenzon)]

OK, do you think this blueprint is connected to the issue or we need another one -
https://blueprints.launchpad.net/mistral/+spec/mistral-error-separation