#There is a discussion about `continue_

1 messages · Page 1 of 1 (latest)

gusty lily
#

Thanks Erik for looking into this
I wasn't aware of 1. so this would be a breaking change for some that have this setup. Im curious was this a feature to have this on non-actions? Or just something that fell through the cracks ?

#

2 & 3 seems like what users are expecting.

#

But! Related to continue on error, there are also signals users would like to act when an error occurs, so for example send a notification "on_error"

#

And not only find about this in traces

#

This would make automations more bulletproof and make the users react to stuff going wrong faster (or even at all), than after the fact

full crane
#

I would suggest to deprecate 1) with a 6 month deprecation period, then things don't suddenly break and we will get feedback if there are genuine use cases for setting continue_on_error on other script actions than action

#

users would like to act when an error occurs, so for example send a notification "on_error"
Sure, I think some sort of feature like that could make sense

gusty lily
#

So we could still detect errors if we do 2 and 3 ?

#

You said "on other actions" - you ment other thing than actions, or not all action can have continue_on_error ?

full crane
#

Right, we have "script actions", which can for example be and or choose or action. I don't see how continue_on_error is useful for and or choose, hence 1)

full crane
# gusty lily So we could still detect errors if we do 2 and 3 ?
  1. doesn't make it harder to detect errors.
  2. changes such that scripts will abort on fewer errors if continue_on_error is set on service call actions, so it means errors are more silent so to speak.
    Is your idea to add some new feature to the script syntax for individual script actions in case there's an error? Or should it be on script level?
gusty lily
#

Not sure yet. I'm afraid doing it per action might be hard to reprenset in the UI we have, because the list view is more suitable for a step-by-step execution, rather than a diverge and continue another path style that is easier to represent on a NODERed style canvas

#

Right now if the continue_on_error would "catch" more cases in traces, but still run the automation, thats a big improvement already. Then users can at least debug better. Adding "on_error" -> do this would be even more foolproof, but that's a new feature to discuss with @formal sentinel

formal sentinel
#

Let's fix continue on error first and consider error handling as a building block or something separately 👍🏻

full crane
#

OK. I'll open PRs for the 3 items I proposed. I'll mark them as draft initially to give the core team some time to react in case there are concerns.

jolly cape
#

cc @gusty cliff

gusty cliff
#

@full crane for #1 what about delay, wait_templates and template errors?

#

same for variables step

#

or conditions with templates

#

I guess even if -> then or chooses

#

I have no idea if these currently capture those types of errors