Juju 3 doesn't report when action fails

[Dragomir Penev]

Tested on Juju 3.1 and 3.2 with the same results.

Investigated for https://github.com/canonical/postgresql-k8s-operator/issues/242
Also reproducible with a test repo https://github.com/dragomirp/action-test

When the action event is failed, there is no output indicating so when using Juju CLI:
$ juju run action-test/0 fail-action

Running operation 1 with 1 task
  - task 2 on unit-action-test-0

Waiting for task 2...

Show task produces no input:
$ juju show-task 8

In juju 2.9, both waiting for the action and seeing the report for the task will display both the failed state and the optional failed message.

The issue seems to be happening on both microk8s and lxd.

[Jack Shaw (jack-shaw)]

This is quite odd. So far I have replicated this on 3.1. Going to confirm on 3.2 and attempt on 3.3 and in-development 4.0

As a temporary work-around, you can try `juju show-operation 1` which should print something like:
```
summary: fail-action run on unit-action-test-1
status: failed
action:
  name: fail-action
  parameters: {}
timing:
  enqueued: 2023-11-21 15:48:10 +0000 GMT
  started: 2023-11-21 15:48:10 +0000 GMT
  completed: 2023-11-21 15:48:10 +0000 GMT
tasks:
  "6":
    host: action-test/1
    status: failed
    timing:
      enqueued: 2023-11-21 15:48:10 +0000 GMT
      started: 2023-11-21 15:48:10 +0000 GMT
      completed: 2023-11-21 15:48:10 +0000 GMT
    message: Fail action failed
    results:
      return-code: 0
```

[Jack Shaw (jack-shaw)]

On further inspection, this is consistent behaviour, just poor communication

`juju run` and `juju show-task` by default print out any results explicitly set by the charm using `event.set_result()` in a yaml format. In the test charm, no results are set.

|You can verify this by adding `event.set_result({"msg": "Fail action failed"}) after line 33 here:
https://github.com/dragomirp/action-test/blob/main/src/charm.py#L33

Whether it should be display if the task succeeded or not here is debate-able. This seems like intended behaviour to me, but I agree this could be much improved. It's bad that this is so mysterious and not communicated properly. We should at the very least return a non-zero retcode in the CLI

You can see the task fails if instead you do `juju show-task 8 --format yaml` or `juju show-operation 7`

[Ian Booth (wallyworld)]

To clarify, the CLI's return code reflects whether the action was queued to run successfully, not the result of running the action. This is like all juju commands.

The "return-code" in the show-task result is the exit code of the action process. An action may choose to run the action-fail hook command to mark the action as having failed, and still exit 0 on the action script itself.

So there's 3 parts to running an action:
- the CLI to queue and monitor progress
- the logic in the action to record results and ultimate success/failure status
- the script itself (and it's exit code)

The action output reflects the latter 2.

[Dragomir Penev (dragop)]

Considering that on Juju 2 we get the failure message, what would be the expected behaviour of a charm that should support both Juju 2 and Juju 3? Use event.set_result() to optionally set a failure message when on Juju 3 or always also set the failure message using event.set_result() regardless of version?

[Jack Shaw (jack-shaw)]

Hi,

We have discussed this a little in the Juju team and the plan of action is that we going to add any failure message to the tabular output during 'run-action'

Hopefully this will be landed in the next patch release of 3.1

[Jack Shaw (jack-shaw)]

PR to fix:

https://github.com/juju/juju/pull/16664