Task notification in state_handlers is still near useless without task inputs. Just saying. Half my flow code is dealing with failed tasks. Even the example on the page on notifications is called sending-a-simple-notification. If you have mapped tasks posting Task failed on slack would be little use when you have 10000 of them.

Hi @Rob Fowler, I will raise this feedback but if you need something immediate, you can add it to the error raised or in the error message, and then grab it in the state handler.

I don't need something immediate. My git ticket has a solution where I override the failure, convert it to success with info telling me it is a failure so later I can filter out the failures and deal with them in the flow.

*def ignore_timeout_handler*(task, old_state, new_state):

*if* new_state.is_failed() *and*

*isinstance*(new_state, state.TimedOut):

*return* state.Success(result=Box(status="TimeOut", stdout="", stderr=""))

*else*:

*return* new_state

Then:

combine = prefect.task(*lambda* first, second: Box(**first, **second))

combined = combine.

*map*(hosts, results)

DumpResultsTask(combined, "all") good_hosts_filter = FilterTask(filter_func=

*lambda* x: x.status == "OK")

DumpResultsTask(good_hosts_filter(combined), "only good with info from datadomain as test") bad_hosts_filter = FilterTask(filter_func=

*lambda* x: x.status != "OK")

DumpResultsTask(bad_hosts_filter(combined), "only bad to email or tell someone") The issue is I do this so many times when, if the handler could get some more info I would never need the code again.

Hey Rob, we've definitely heard this feature request before but it is not compatible with the current concept of a state handler. As the name suggests, state handlers are called on all state transitions, including

Pending

->

Running

and

Failed

->

Retrying

and there is only one, maybe two, transitions for which "inputs" are even a meaningful and known quantity. Rephrased, state handlers are hooks that operate in the surface area around your task as an isolated unit (including all the times the task is not able to run and doesn't even have inputs). With all feature requests we need to be able to have an open conversation about the desired outcome because, as is the case here, your intended goal is not actually compatible with the current concept of state handlers so a new hook or a re-imagining is needed. This conversation can be difficult to have when it begins with "This feature is useless" 🙂

Yes. Sorry for the hate. In fact I know I am not going to get it. But, as I said, you example is do a slack notification on state transition. The state transition system is of very limited use in feedback without any context but the old and new state. May I suggest you change the documentation (or I can PR it) to something else, maybe my example above and not 'post to slack'.