Block with rescue stops next plays and end playbook successfully on some errors #73657
Comments
|
Files identified in the description: If these files are incorrect, please update the |
ansibot
added
affects_2.10
samdoran
removed
the
needs_triage
|
An incorrect module name is a syntax error. Rescue does not apply to syntax errors, but we'll look into a but further just to make sure this isn't a bug. |
|
I don't mind too much the playbook stopping if there is a syntax error (although it's not what I want too), but there are some aspects that makes it clearly a bug:
It should either stop the current play immediately and fail (not what I want, but I would be ok with it), or rescue and continue all the next plays (which is what I want). But it does neither one nor the other, it continues the play, don't run the next plays (stops abruptly at the end of the play), and ends the execution partially with a success status. |
|
|
Since this is a parsing error the play execution should not continue and we should probably mimic the behavior of diff --git a/lib/ansible/plugins/strategy/__init__.py b/lib/ansible/plugins/strategy/__init__.py
index eaa7c0cb20..96910301b1 100644
--- a/lib/ansible/plugins/strategy/__init__.py
+++ b/lib/ansible/plugins/strategy/__init__.py
@@ -954,7 +954,8 @@ class StrategyBase:
# first processed, we do so now for each host in the list
for host in included_file._hosts:
self._tqm._stats.increment('ok', host.name)
-
+ except AnsibleParserError:
+ raise
except AnsibleError as e:
if isinstance(e, AnsibleFileNotFound):
reason = "Could not find or access '%s' on the Ansible Controller." % to_text(e.file_name)
diff --git a/lib/ansible/plugins/strategy/free.py b/lib/ansible/plugins/strategy/free.py
index 7e0406984d..653291b327 100644
--- a/lib/ansible/plugins/strategy/free.py
+++ b/lib/ansible/plugins/strategy/free.py
@@ -34,7 +34,7 @@ DOCUMENTATION = '''
import time
~
from ansible import constants as C
-from ansible.errors import AnsibleError
+from ansible.errors import AnsibleError, AnsibleParserError
from ansible.playbook.included_file import IncludedFile
from ansible.plugins.loader import action_loader
from ansible.plugins.strategy import StrategyBase
@@ -255,6 +255,8 @@ class StrategyModule(StrategyBase):
)
else:
new_blocks = self._load_included_file(included_file, iterator=iterator)
+ except AnsibleParserError:
+ raise
except AnsibleError as e:
for host in included_file._hosts:
iterator.mark_host_failed(host)
diff --git a/lib/ansible/plugins/strategy/linear.py b/lib/ansible/plugins/strategy/linear.py
index d22f03e9f0..a345cf1f77 100644
--- a/lib/ansible/plugins/strategy/linear.py
+++ b/lib/ansible/plugins/strategy/linear.py
@@ -32,7 +32,7 @@ DOCUMENTATION = '''
'''
~
from ansible import constants as C
-from ansible.errors import AnsibleError, AnsibleAssertionError
+from ansible.errors import AnsibleError, AnsibleAssertionError, AnsibleParserError
from ansible.executor.play_iterator import PlayIterator
from ansible.module_utils.six import iteritems
from ansible.module_utils._text import to_text
@@ -383,7 +383,8 @@ class StrategyModule(StrategyBase):
else:
all_blocks[host].append(noop_block)
display.debug("done iterating over new_blocks loaded from include file")
-
+ except AnsibleParserError:
+ raise
except AnsibleError as e:
for host in included_file._hosts:
self._tqm._failed_hosts[host.name] = TrueThen the error is fatal: |
|
About number 1, the fact that is dynamic is exactly the reason that makes me expect it to not error the entire execution. With an import task I would probably receive an error before the playbook start executing (I have not tested, but I guess it what happens). If I have tasks at the final play that destroy any resource created at the beginning, I would expect it to run if some task included in the middle of the execution gave a syntax error (inside the task, after the resources were already created in previous steps), but had a That said, I would still be ok if it failed immediately and returned an error (solve 2 and 3). |
* Parser errors from within includes should not be rescueable * Also fixes unit tests Fixes #73657
…73722) * Parser errors from within includes should not be rescueable * Also fixes unit tests Fixes ansible#73657
SUMMARY
Depending on the error that occurs when a block with rescue catches it, the play execution stops, and the playbook ends successfuly, but the next plays don't run. I was able to simulate it using
include_tasks, but the task inside use a module with a wrong name (that can be provided by a user, so not something that I have control, because it might not be me running the play, the user may include and run custom tasks).This is not a problem if the module with wrong name is in the main playbook file, because the playbook fails at compilation time, but when lazily loaded through an
include_tasks, the task fails, therescue(wrapping theinclude_tasks) catches the error successfully, but the next plays don't run, and the playbook ends successfuly.ISSUE TYPE
COMPONENT NAME
block
ANSIBLE VERSION
CONFIGURATION
(
ansible-config dump --only-changedoutputs nothing)OS / ENVIRONMENT
Ubuntu 18.04 (docker container)
STEPS TO REPRODUCE
hosts.yml:
playbook.yml:
Works:
test.yml (gives an error, but works as expected):
Outputs:
PLAY [Test 01] ************************************************************************************************************************ TASK [include_tasks] ****************************************************************************************************************** included: /main/dev/repos/cloud/test.yml for localhost TASK [ansible.builtin.file] *********************************************************************************************************** fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unsupported parameters for (ansible.builtin.file) module: param Supported parameters include: _diff_peek, _original_basename, access_time, access_time_format, attributes, follow, force, group, mode, modification_time, modification_time_format, owner, path, recurse, selevel, serole, setype, seuser, src, state, unsafe_writes"} TASK [debug] ************************************************************************************************************************** ok: [localhost] => { "msg": "rescued" } TASK [debug] ************************************************************************************************************************** ok: [localhost] => { "msg": "test 01" } PLAY [Test 02] ************************************************************************************************************************ TASK [debug] ************************************************************************************************************************** ok: [localhost] => { "msg": "test 02" } TASK [fail] *************************************************************************************************************************** fatal: [localhost]: FAILED! => {"changed": false, "msg": "end here"} PLAY RECAP **************************************************************************************************************************** localhost : ok=4 changed=0 unreachable=0 failed=1 skipped=0 rescued=1 ignored=0Bug:
test.yml (gives an error, stops the next plays, ends the playbook successfully, as explained above):
Outputs:
PLAY [Test 01] ************************************************************************************************************************ TASK [include_tasks] ****************************************************************************************************************** fatal: [localhost]: FAILED! => {"reason": "couldn't resolve module/action 'wrong.collection.module'. This often indicates a misspelling, missing collection, or incorrect module path.\n\nThe error appears to be in '/main/dev/repos/cloud/test.yml': line 1, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- wrong.collection.module:\n ^ here\n"} TASK [debug] ************************************************************************************************************************** ok: [localhost] => { "msg": "rescued" } TASK [debug] ************************************************************************************************************************** ok: [localhost] => { "msg": "test 01" } PLAY RECAP **************************************************************************************************************************** localhost : ok=2 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0EXPECTED RESULTS
The same as in the case that works.
ACTUAL RESULTS
Stop the next plays, even after being rescued, and end the playbook successfully (if I run
ansible-playbook playbook.yml && echo "success" || echo "error"it gives an error (due to thefailtask at the end) in the 1st case (that works), but success in the 2nd, and don't run the 2nd play).The text was updated successfully, but these errors were encountered: