I understand there are 2 ways to run a Script. Use the script: command/action directly or use script_turn_on:.
According to the docs, the former is synchronous operation and the caller waits for the called Script to end before proceeding itself, but the latter is asynchronous and calls the Script, but then immediately continues so errors in the called script won’t interrupt the caller.
However I have had several instances when using script_turn_on: that an error in the called script DOES halt the caller (Script or Automation) and leaves it in a continually running state and not available to be run again until the ‘blockage’ is somehow cleared.
Isn’t this exactly what using script_turn_on: is supposed to avoid? Or am I misunderstanding the difference between these 2 methods of calling a Script.
Create a simple example that reliably reproduces this misbehavior and submit it as a new Issue in Home Assistant’s Github Core repository.
Because without an example that produces the anomaly, there’s insufficient evidence to begin an investigation or a benchmark test for determining what fixes it.
Not exactly syntax issues, but yes the called script had a problem. However, my understanding was that using script_turn_on avoided that being a problem.
My thinking now is that if there is a problem initially calling the script, then even script_turn_on will still halt the calling script. Only if the called script has an error while running does script_turn_on avoid hanging the calling script.
It’s a subtle but important difference and in the former case the called script shows a trace, but that contains no steps that might indicate the problem. The trace exists but is empty, even though the calling script clearly did call it according to its trace.
Just how the history is recored I guess and now I know that, it will be easier to figure what happened if this occurs again.