LEARN. PRACTICE. GROW.Concept and mechanism
A task can succeed without changing state; another can change files without producing a usable service. Define failed_when and changed_when from the operation contract. A failed_when condition list uses implicit conjunction: if failure is required when any condition occurs, express the intended disjunction. For textual flags, normalize using an appropriate conversion instead of assuming the string false is always interpreted as Boolean false. Handlers are notified by changes and normally wait for defined boundaries. If a check depends on loaded configuration, ensure pending handlers have run before that check.
Guided application
Blocks with rescue enable recovery but do not automatically catch every problem. Definition errors and unreachable hosts do not follow the same rescue path as an ordinary failed task. Successful rescue can permit continuation, including avoiding failure thresholds someone expected to trigger. In a fictional rollout, rollback works but acceptance policy requires stopping after functional failure. Encode that decision explicitly. Serial controls host batches; forks controls concurrent execution capacity and is not equivalent to accepted batches. Include functional checking and reentry before advancing. The team should distinguish service recovery, change acceptance, and authorization to continue expansion.
Successful rollback recovers the previous service; it does not show the new version was accepted.
Common pitfalls
List as OR; rescue as universal catch; forks as serial; recovery as approval.
Related topics: State and repeatability · Inventories, variables, and configuration · Access and execution environment
Make automation stop under the same conditions the team uses to decide.
Reference: Block rescue and always · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned