Krikri::HandlerNotFoundError

Raised at RUN time - from TaskExecutor#notify_handlers, at the moment a task actually notifies - when the notified name matches no handler's name and no handler's listen: topic. Real Ansible aborts the whole run there and then ("ERROR! The requested handler '...' was not found in either the main handlers list nor in the listening handlers list", rc=1, no PLAY RECAP printed), rather than silently no-opping the notification the way this engine's handler dispatch (HandlerRunner#should_run_handler?) otherwise does - which let a role's own typo'd/stale notify: target go completely unnoticed (robertdebock.roundcubemail, round93: notify: restart httpd with no matching Debian handler, the whole role "succeeding" with apache's new vhost never activated).

This used to be a PARSE-time sweep over every literal notify: name in the play, which is not where real Ansible checks: verified against ansible-core 2.19.4, a notify: naming a nonexistent handler is an error ONLY if the notifying task actually fires the notification - a task that reports ok (unchanged), or is skipped by its when:, notifies nothing and the run completes green. The parse-time version aborted all three cases with rc=4, failing playbooks real Ansible runs fine, and simultaneously MISSED a bad notify inside an include_tasks:-loaded file, which no parse-time sweep can see at all (buluma.phpmyadmin's own setup-Debian.yml, round 181: notify: restart apache, a handler nothing in its dependency chain defines - real Ansible aborts, this engine ran the role to completion).