Krikri::ActionResult

Create a failure result raised by the ACTION plugin itself (a bare AnsibleActionFail - add_host's "name, host or hostname needs to be provided"): rendered action-level, not module-level (see #action_level).

Create a failure raised by an UNCAUGHT Python exception inside the action plugin - the codec-stack crash Ansible's template action plugin dies with on a non-string output_encoding ("encode() argument 'encoding' must be str, not _AnsibleTaggedInt"), its unknown-codec LookupError, and the #jinja2: directive TypeError (whose crash origin is the template file - see #error_origin). Ansible's task executor wraps such an exception itself, so the fatal dump's msg keeps the "Task failed: " prefix while the [ERROR] block shows the bare message (see #error_detail). undef_chain (see #undef_chain) additionally asks the executor for the failing VALUE's own chained Origin - its var-definition layers.

Create failure result

Create a final, controller-computed result - no module ever runs.

Create pass-through result (no modifications)

Create success result

The result shape for a CONDITIONAL-EVALUATION failure (assert:'s that: hitting an undefined reference or a non-bool result). ansible-core 2.19.11 (live-verified: assert: that: undef_var == 1 with register:) registers changed=false+failed=true+msg and dumps the fatal line as {"changed": false, "msg": "Task failed: ..."} - the same shape as the when:/ path's when_error_result; an older 2.19 build showed a changed-less registered var, but 2.19.11 is the parity target. An ordinary failing assertion still registers changed: false alongside via plugin_result_json.

Shared builder for the flat result hash PluginResult#to_json produces (changed/failed/msg + extra fields at the top level, no nesting) - used by every final-result action plugin (action_plugins/*.cr) so each one only needs to name its own extra fields, not re-derive this shape.

Set when the failure was raised by the controller-side ACTION plugin itself (a bare AnsibleActionFail): the [ERROR] block is the plain "Task failed: <msg>" chain with no "Module failed." middle segment and the fatal dump's msg stays un-prefixed, unlike a module-side failure. The executor's action-failure result builders turn this into the result's _ansible_action_level key (see ResultDisplay's own branch).

Set when the failure was raised by the controller-side ACTION plugin itself (a bare AnsibleActionFail): the [ERROR] block is the plain "Task failed: <msg>" chain with no "Module failed." middle segment and the fatal dump's msg stays un-prefixed, unlike a module-side failure. The executor's action-failure result builders turn this into the result's _ansible_action_level key (see ResultDisplay's own branch).

The [ERROR] block's own text when it differs from the result's msg. Ansible's task executor wraps an UNCAUGHT Python exception raised inside an action plugin itself ("Task failed: %s" % to_native(e)), so such a failure's fatal msg carries that prefix while the block still shows the bare message - which is what this carries. A deliberate AnsibleActionFail has no prefix in either place, so it stays nil.

The [ERROR] block's own text when it differs from the result's msg. Ansible's task executor wraps an UNCAUGHT Python exception raised inside an action plugin itself ("Task failed: %s" % to_native(e)), so such a failure's fatal msg carries that prefix while the block still shows the bare message - which is what this carries. A deliberate AnsibleActionFail has no prefix in either place, so it stays nil.

The file whose Origin the [ERROR] block's CAUSE segment carries when the crash happened while parsing/rendering THAT file rather than in the task's own YAML - ansible's event source context comes from the offending value's own origin tag, so template:'s #jinja2: directive TypeError is reported against the TEMPLATE file (round 1500121, apolloclark.packetbeat). nil = the cause carries no Origin, the shape every other crash_failure has today.

The file whose Origin the [ERROR] block's CAUSE segment carries when the crash happened while parsing/rendering THAT file rather than in the task's own YAML - ansible's event source context comes from the offending value's own origin tag, so template:'s #jinja2: directive TypeError is reported against the TEMPLATE file (round 1500121, apolloclark.packetbeat). nil = the cause carries no Origin, the shape every other crash_failure has today.

Set only by an action plugin that computes the task's ENTIRE result on the controller and needs no module invocation at all (debug:/ assert:/fail:/set_fact:/pause: - see their own action-plugin files under action_plugins/). When present, the caller (prepare_batch_step / execute_task_once / the handler path) skips plugin upload/dispatch entirely and uses this JSON as the task's result verbatim (still passed through apply_changed_failed_when, same as any other result) - distinct from modified_params, which still expects a real module (local or remote) to run afterward with the substituted params (template:'s own use).

Set only by an action plugin that computes the task's ENTIRE result on the controller and needs no module invocation at all (debug:/ assert:/fail:/set_fact:/pause: - see their own action-plugin files under action_plugins/). When present, the caller (prepare_batch_step / execute_task_once / the handler path) skips plugin upload/dispatch entirely and uses this JSON as the task's result verbatim (still passed through apply_changed_failed_when, same as any other result) - distinct from modified_params, which still expects a real module (local or remote) to run afterward with the substituted params (template:'s own use).

template:'s undefined-variable render failure (see TemplateAction Plugin): the crash shape PLUS a request for the executor's chained var-origin lookup. When the missing name is reached through a VARIABLE whose stored value is itself an unrendered {{ }} (server_ip: "{{ bind_addr }}"), real 2.19.11 points the [ERROR] chain's variable-templating link at that DEFINITION's file:line:col with a code frame (live-captured) - the executor owns the layers that carry those origins, so the plugin only asks for the scan (it falls back to the crash-shape default, the template file, when the scan finds no unique answer).

template:'s undefined-variable render failure (see TemplateAction Plugin): the crash shape PLUS a request for the executor's chained var-origin lookup. When the missing name is reached through a VARIABLE whose stored value is itself an unrendered {{ }} (server_ip: "{{ bind_addr }}"), real 2.19.11 points the [ERROR] chain's variable-templating link at that DEFINITION's file:line:col with a code frame (live-captured) - the executor owns the layers that carry those origins, so the plugin only asks for the scan (it falls back to the crash-shape default, the template file, when the scan finds no unique answer).