ManagementApi: Target Action status does not reflect actual status

[reppners]

When requesting an action from the ManagementApi the returned Action's current status is reduced from an explicit Action status property to either pending or finished. This leads to wrong information and also makes the status information less useful since it then is unknown to the user of the ManagementApi if the action was canceled, errored or is in some other state. E.g. if an action is in scheduled state because of a rollout the ManagementApi will report this action as finished.

I'd much rather would like to have the Status as it exists on the internal JpaAction in favor of the pending, finished status abstraction which just resembles isActive.

[stefbehl]

Hello @reppners, thanks for opening this issue!

We've been discussing it today and we want to make sure we fully understand your requirement.

For an action, the Mgmt API exposes the following two properties to describe its overall status:

• type: ['update', 'cancel']
• status: ['finished', 'pending'] See Targets for more details.

So basically the only information that is missing is whether or not the action was finished successfully or with an error, right?

We can try to add this information to the JSON representation of an action. However, to avoid an API break, we tend to add a new property 'finishedStatus' or 'result' with values 'success' or 'failure' (the exact approach and in particular the property names are still being discussed).

Thanks and regards Stefan

[reppners]

Hi! Thanks for the insight on your discussions!

So basically the only information that is missing is whether or not the action was finished successfully or with an error, right?

Almost, since an action can also be sort of in between when it is in the scheduled state. This may be important information if a target is being monitored and it is part of a rollout. (Without somebody knowing that a particular target currently is part of a rollout).

Ideally all states defined here: https://github.com/eclipse/hawkbit/blob/732e8cc746d1df167641ca704e1626fc6101c359/hawkbit-repository/hawkbit-repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/model/JpaAction.java#L99-L114 get translated to the MgmtApi Action in some shape or form, because otherwise for each action the states have to be queried to get hold of that information.

How do you think about the scheduled actions being reported as finished? Adding another possible status scheduled may already break some clients in case of enum parsing, so maybe those could be reported as pending instead of finished 🤷‍♂️

I agree that going forward by adding properties to avoid a breaking change is the best approach 👍

[stefbehl]

Hi @reppners - just found that there is a REST entry point for retrieving the exact status of an action. In the JSON representation of an action, there is a link with link relation "status":

{
  "createdBy" : "bumlux",
  "createdAt" : 1617968307580,
  [..]
  "_links" : {
    "self" : {
      "href" : "https://management-api.host.com/rest/v1/targets/137/actions/17"
    },
    "status" : {
      "href" : "https://management-api.host.com/rest/v1/targets/137/actions/17/status?offset=0&limit=50&sort=id:DESC"
    }
  },
  "id" : 17,
  "forceType" : "timeforced"
}

If you follow that link you will get the detailed action status:

HTTP/1.1 200 OK
Content-Length: 262
Content-Type: application/hal+json;charset=UTF-8

{
  "content" : [ {
    "type" : "finished",
    "messages" : [ null ],
    "reportedAt" : 1610633137114,
    "id" : 31
  }, {
    "type" : "running",
    "messages" : [ null ],
    "reportedAt" : 1610633137105,
    "id" : 30
  } ],
  "total" : 2,
  "size" : 2
}

The property "type" holds the detailed state of the action: ['finished', 'error', 'warning', 'pending', 'running', 'canceled', 'retrieved', 'canceling']

See also Mgmt REST API Docs, entry point "GET /rest/v1/targets/{targetId}/actions/{actionId}/status".

That's exactly what you have been looking for, right?

Thanks and regards Stefan

[reppners]

This could be used, but I'd like to avoid the second request necessary for each action to get the info necessary to determine if the current action status is of interest. Also this does not solve the issue of finished actions that are actually scheduled. It can be detected, because for a scheduled action there are 0 status entries but this feels more like a hack then an actual solution.