Guidance on tasks that ignore error

[waded]

Is there any guidance on designing tasks that would ignore errors?

I read task output like this:

TASK [whatever : Shut down something] **********************************************
fatal: [10.140.2.225]: FAILED! => {"changed": false, "failed": true, "msg": "systemd could not find the requested service "'something'": "}
...ignoring

in red and my first thought is WHY is that ignored?

Would it make sense to have guidelines around naming of the task to include the reason for ignored error?, as extra assurance that this is is an 'expected exception' not just a patch around an error condition we don't understand?

E.g. here, if the task was named "Shut down something, ignore since user may have already shut it down" I might feel better.

Or perhaps something is wrong at a higher level with this pattern... perhaps we should have guidance that ignore should never be used UNLESS it is expected exception. It still does end up being red output. :(

[brikr]

Good point,
I think most of the time the reasoning here is included in the comments of the playbook, which isn't very helpful to the user running the task. This explanation should be moved to the task name.
Additionally, if shell tasks (the most common tasks I've seen ignore_errors: true on) are expected to "fail", the programmer should research ways to make the shell command itself ignore errors, as most programs have options to not fail when something expected goes wrong (e.g. -f option in rm, which will not error if the file does not exist).