Krikri::HandlerRunner

Check if any handlers were notified

Clears every host's notified-handler set, so a subsequent #run call (from a later meta: flush_handlers, or the final end-of- play flush) only picks up handlers notified SINCE the last flush, not ones already run. Real Ansible's own flush_handlers has this same "only runs what's still pending" semantics - a handler already flushed once doesn't run a second time just because the end-of-play flush also fires.

Notify a handler (by name or listen topic) Handlers can be notified multiple times but only run once

Run all notified handlers Handlers run in the order they are defined, not the order they were notified This matches Ansible behavior

name_resolver renders a handler's own name: against its real vars_context (mirrors TaskExecutor#render_task_name_for_display - HandlerRunner has no vars_context machinery of its own, so this is threaded in the same way execute_callback already is). Needed because a role-loaded handler's name is frequently itself a template (prometheus.prometheus's own _common role: name: "Restart {{ _common_service_name }}") - matching against the raw, unrendered handler.name (as this used to) never equals any real notify: string. halted_hosts - hosts a prior task already failed on (unrescued, no ignore_errors:) for this run. Real Ansible never runs a halted host's own notified handlers at the end-of-play flush - once a host is out, it's out entirely, handlers included. Previously unfiltered: @hosts.each below ran unconditionally, so a host whose LAST regular task failed (round 83's robertdebock.keepalived: "Start keepalived" times out and halts the host) still ran its own previously-notified "Restart keepalived" handler at the implicit end-of-play flush, since that flush happens after halt_if_failed already halted the host but before this method had any way to know. Real Ansible shows exactly one failure (the halting task); krikri-playbook showed two (the halting task, then the handler that should never have run).