LEARN. PRACTICE. GROW.Concept and mechanism
An execution summary needs to be read by host and task. Failed and unreachable represent different problems: a task may have run and returned failure, or the executor may have been unable to contact the target. ignore_errors does not indiscriminately cover connection errors, undefined variables, or invalid syntax. Define failed_when with attention to logic: a condition list uses implicit AND; when either condition suffices, express OR. An error can occur after other tasks changed files. Overall failure does not establish absence of effects, and the next run should start from observed actual state.
Guided application
Blocks organize rescue and always sections but are not a transaction that automatically undoes changes. Unreachable hosts and invalid definitions do not trigger those sections like a task with failed status. Successful rescue changes continuation and threshold handling; verify it recovered function rather than merely completed. In a fictional case, a template notified a restart, but another task failed before the handler. The new file may coexist with the old process. force_handlers can address some failures but does not make an unreachable host reachable. Decide recovery using file, service, connectivity, and data state, and hand RUN evidence of function and remaining limitations.
A changed file and unexecuted handler require reconciling disk configuration with the running process.
Common pitfalls
Rescue as automatic rollback; always without exceptions; ignoring unreachable; command success as functional recovery.
Related topics: Inventory and execution context · Tasks and desired state · Validation and handlers
Recover function using evidence of partial state and affected scope.
Reference: Error handling in playbooks · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation