Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ansible_failed_task is not working reliably with inner blocks #43191

Closed
barlik opened this issue Jul 24, 2018 · 1 comment · Fixed by #78676
Closed

ansible_failed_task is not working reliably with inner blocks #43191

barlik opened this issue Jul 24, 2018 · 1 comment · Fixed by #78676
Labels
affects_2.7 This issue/PR affects Ansible v2.7 affects_2.11 affects_2.13 bug This issue/PR relates to a bug. has_pr This issue has an associated PR. P3 Priority 3 - Approved, No Time Limitation support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@barlik
Copy link
Contributor

barlik commented Jul 24, 2018 •
edited

SUMMARY

When using blocks inside other blocks, variable ansible_failed_task is not propagated reliably.

ISSUE TYPE
  • Bug Report
COMPONENT NAME

core engine

ANSIBLE VERSION
ansible 2.7.0.dev0 (task-retries 7dda294680) last updated 2018/07/22 11:26:54 (GMT +100)
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/kerny/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/kerny/dev/github/ansible/lib/ansible
  executable location = /home/kerny/dev/github/ansible/bin/ansible
  python version = 3.6.6 (default, Jun 27 2018, 13:11:40) [GCC 8.1.1 20180531]
CONFIGURATION

stock configuration

OS / ENVIRONMENT

Linux

STEPS TO REPRODUCE
- hosts: localhost
  connection: local
  tasks:
    - name: outer block
      block:
        - name: inner block
          block:
            - fail:
          always:
            - debug:
      rescue:
        # here ansible_failed_task is undefined
        # however, it will be defined when you comment out above always block
        - debug: var=ansible_failed_task.action
EXPECTED RESULTS
TASK [debug] **********************************************************************************
ok: [localhost] => {
    "ansible_failed_task.action": "fail"
}
ACTUAL RESULTS
TASK [debug] **********************************************************************************
ok: [localhost] => {
    "ansible_failed_task.action": "VARIABLE IS NOT DEFINED!"
}
@ansibot
Copy link
Contributor

ansibot commented Jul 24, 2018

Files identified in the description:
None

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added affects_2.7 This issue/PR affects Ansible v2.7 bug This issue/PR relates to a bug. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Jul 24, 2018
@barlik barlik mentioned this issue Jul 24, 2018
Merged
@jborean93 jborean93 removed the needs_triage Needs a first human triage before being processed. label Jul 26, 2018
@ansibot ansibot added the has_pr This issue has an associated PR. label Jul 27, 2019
mkrizek added a commit to mkrizek/ansible that referenced this issue Oct 26, 2020
@mkrizek
Fix ansible_failed_task with inner always and outer rescue blocks
259523a 
ci_complete

Fixes ansible#43191
@mkrizek mkrizek mentioned this issue Oct 26, 2020
Closed
mkrizek added a commit to mkrizek/ansible that referenced this issue Dec 11, 2020
@mkrizek
Fix ansible_failed_task with inner always and outer rescue blocks v2
083e6cc 
Rather then trying to iterate states to figure out whether the next task
will be in a rescue portion of the block and if so set
ansible_failed_task/ansible_failed_result variables, we could just look
if rescue portion of the block exists in any block from top down to the
most nested one. That way we do not have to handle various corner cases
where iterating to next task would end up in an always section but
rescue section would be in an outer block and we would fail to set the
variable.

Fixes ansible#43191
mkrizek added a commit to mkrizek/ansible that referenced this issue Dec 11, 2020
@mkrizek
Fix ansible_failed_task with inner always and outer rescue blocks v2
454c89f 
Rather then trying to iterate states to figure out whether the next task
will be in a rescue portion of the block and if so set
ansible_failed_task/ansible_failed_result variables, we could just look
if rescue portion of the block exists in any block from top down to the
most nested one. That way we do not have to handle various corner cases
where iterating to next task would end up in an always section but
rescue section would be in an outer block and we would fail to set the
variable.

Fixes ansible#43191

ci_complete
@mkrizek mkrizek mentioned this issue Dec 11, 2020
Closed
mkrizek added a commit to mkrizek/ansible that referenced this issue Jan 27, 2021
@mkrizek
Fix ansible_failed_task with inner always and outer rescue blocks v2
c955827 
Rather then trying to iterate states to figure out whether the next task
will be in a rescue portion of the block and if so set
ansible_failed_task/ansible_failed_result variables, we could just look
if rescue portion of the block exists in any block from top down to the
most nested one. That way we do not have to handle various corner cases
where iterating to next task would end up in an always section but
rescue section would be in an outer block and we would fail to set the
variable.

Fixes ansible#43191

ci_complete
@s-hertel s-hertel added affects_2.13 P3 Priority 3 - Approved, No Time Limitation labels Nov 12, 2021
mkrizek added a commit to mkrizek/ansible that referenced this issue Nov 12, 2021
@mkrizek
Fix ansible_failed_task with inner always and outer rescue blocks v2
e10df74 
Rather then trying to iterate states to figure out whether the next task
will be in a rescue portion of the block and if so set
ansible_failed_task/ansible_failed_result variables, we could just look
if rescue portion of the block exists in any block from top down to the
most nested one. That way we do not have to handle various corner cases
where iterating to next task would end up in an always section but
rescue section would be in an outer block and we would fail to set the
variable.

Fixes ansible#43191

ci_complete
@mkrizek mkrizek mentioned this issue Aug 18, 2022
Merged
mkrizek added a commit to mkrizek/ansible that referenced this issue Aug 31, 2022
@mkrizek
Propagate ansible_failed_task to an outer rescue
7709339 
Fixes ansible#43191
Fixes ansible#72638

ci_complete
@mkrizek mkrizek mentioned this issue Aug 31, 2022
Merged
@mkrizek mkrizek closed this as completed in fd19ff2 Sep 6, 2022
@ansible ansible locked and limited conversation to collaborators Sep 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
affects_2.7 This issue/PR affects Ansible v2.7 affects_2.11 affects_2.13 bug This issue/PR relates to a bug. has_pr This issue has an associated PR. P3 Priority 3 - Approved, No Time Limitation support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Milestone
No milestone
5 participants
@relrod @ansibot @jborean93 @barlik @s-hertel