Problem regarding the preferred order of the key-order[task] rule of name, block, and rescue

[brlin-tw]

Today I found that one of my role's integration failed with the following error:

key-order[task]: You can improve the task key order to: name, block, rescue
tasks/main.yml:1 Task/Handler: Doing a connectivity critical task

And my tasks list looks like this:

- name: Doing a connectivity critical task
  rescue:
    - name: Rollback configuration to avoid losing access to the managed host when either of the task in the block failed
      ...
  block:
    - name: Do something dangerous

I found the name-rescue-block task key order to be helpful as the error handling logic will not be push further down the screen, which is also the justification reasoning of the name-when-block ordering. I know that this order preference is not consistent with the order of the traditional try-catch error handling coding style but I'm curious why the name-block-rescue order is consider to be preferable other than that reasoning.

Thanks in advance!

[eb4x]

The other reason it's preferable is because that's the way the code will run when you read the playbook. It's always going to start with the tasks in block. I think that's a good enough reason they would come first.

If and only if any of the tasks in the block fail, will it stop executing tasks in block and start executing tasks in rescue.

You can also have an always section. Those tasks would run last. After block if no errors or rescue if errors.

Also I'm not sure what you're trying to do with when: block_failed. It's either not needed, or a bit misleading. You could write something like when: that_specific_task_in_block is failed. (As an example, if you only need to run a rescue task when the 3rd task in block failed)

[brlin-tw]

Also I'm not sure what you're trying to do with when: block_failed. It's either not needed, or a bit misleading.

I've modified the example task list to fix the problem, thanks for the heads up!

[brlin-tw]

I would suggest considering either of the following orders valid:

• name-block-rescue
• name-rescue-block

[eb4x]

The case for moving the when clause to before the block is really a stroke of genius. I'd almost recommend doing that for all tasks, as it just makes playbooks read better.

- name: perform complicated monitoring setup
  when: enable_monitoring
  block:
    - name: Install packages
      ...

The when clause applies to all tasks in the block/rescue/always. It's really rather important. It helps you determine whether or not the tasks are even relevant for you to even look at. By moving it before the block, it's right there in your face. You're not spending time reading through a large block, only at the very end to find a when clause, letting you know it's all irrelevant.

I think block/rescue/always keeps expected order of execution consistent with reading the playbook. rescue sections can also get so huge they squeeze out the block, which would make your argument for it's placement less compelling. And where would you put always in your equation?

I think if you feel you've got things under control with the way you like to do things, just add

skip_list:
  - key-order[task]

to your .ansible-lint, and don't care what the linter-team tells you about bad form 😺

I've got name[missing] in mine. Because if import_tasks: ain't gonna display the name section, I'm not adding one 😈