Stop script if sub-script stops or aborts

[emontnemery]

Proposed change

Stop script if sub-script stops or aborts

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes stop action only stops active sequence, not entire script #70999
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[frenck]

Thanks, @emontnemery 👍

[KevinCathcart]

Is this not a breaking change? Certainly some people could be accidentally or even deliberately relying on existing aborts not bubbling up.

And in one case I think the current behavior is documented:

The condition action only stops executing the current sequence block. When it is used inside a repeat action, only the current iteration of the repeat loop will stop. When it is used inside a choose action, only the actions within that choose will stop.

But the condition action looks to work by raising _AbortScript. With this change that now bubbles upward?

Perhaps I am missing something though. I'm only reading the code, not actually testing this change out.

[frenck]

Perhaps I am missing something though. I'm only reading the code, not actually testing this change out.

That doesn't rely on aborting.

Those are condition errors, which are caught to break the loop.

[KevinCathcart]

But I'm talking about condition as an action type within a choose branch or within a loop. https://www.home-assistant.io/docs/scripts/#test-a-condition

The condition action step looks to be turning failed conditions or ConditionErrors into an abort:

core/homeassistant/helpers/script.py

Lines 711 to 729 in d6ff476

	async def _async_condition_step(self):
	"""Test if condition is matching."""
	self._script.last_action = self._action.get(
	CONF_ALIAS, self._action[CONF_CONDITION]
	)
	cond = await self._async_get_condition(self._action)
	try:
	trace_element = trace_stack_top(trace_stack_cv)
	if trace_element:
	trace_element.reuse_by_child = True
	check = cond(self._hass, self._variables)
	except exceptions.ConditionError as ex:
	_LOGGER.warning("Error in 'condition' evaluation:\n%s", ex)
	check = False
	self._log("Test condition %s: %s", self._script.last_action, check)
	trace_update_result(result=check)
	if not check:
	raise _AbortScript

[frenck]

Meh that looks like a totally different bug in that case.
(As the repeat loops now check for a ConditionError that can never been thrown as it seems).

[KevinCathcart]

Are the conditions of the loop actually treated as action steps? Or just evaluated more directly?

In any case be 100% clear about the case I am referring to, I'm talking about scripts like this one which should make the left light blink at twice the rate of the right light. I've hand typed this, so i may have messed something up.

      - repeat:
          count: 16
          sequence:
            - delay: 2
            - service: light.toggle
              target:
                entity_id: "light.left"
            - alias: ignore odd indexes for the right light
              condition: "{{ repeat.index % 2 == 0 }}"
            - service: light.toggle
              target:
                entity_id: "light.right"

The condition failing is like a continue statement here, at least if the docs are accurate.

But the same concept also applies to choose statements. where the conditional failing would act sort-of like a break statement within a switch in C like languages, except that choose lacks fall-though.

[emontnemery]

@KevinCathcart #71235 makes sure a failing condition in a sub-script does not bubble up and stops the parent.