Accepting cancellation doesn't work

[ctron]

Steps:

• Schedule update
• Cancel update
• Device accepts cancellation
• Server responds with 200, but writes in the log Update Server: Target reported cancel for a cancel which is not supported by the server.
• Next time the status is fetched, the cancel link is still present

Server state:

{"id":"3","cancelAction":{"stopId":"3"}}

Device response:

"id": "3",
  "status": {
    "details": [],
    "execution": "canceled",
    "result": {
      "finished": "none"
    }
  }
}

Using Hawkbit: 0.3.0.M6

[laverman]

Hi @ctron - we definitely need to improve our documentation here. Sorry for that.

If the server sends a cancel request the idea is, that the device cancels the update and afterwards feedbacks 'closed' / finished 'success' to the server, as the update-action is done. In case the cancellation wasn't successful, the finished state would be 'failure'.

If the client wants to initiate a cancel, it would feedback 'canceled' to indicate the cancellation intent. To close the update-action, the client still needs to feedback the server, that the action is closed (either successful or with failure).

NOTE: The first cancel arrow does not mean, that this is pushed to the device, but is part of the response body, when the device polls its root resource.

[ctron]

Thanks for the explanation. So which endpoint would each actions target? As there is cancel and deploymentBase endpoint?

[laverman]

When the update is assigned, the root resource of the devices /controller/v1/{controllerId} exposes a link to the deploymentBase.

[First Interaction] If the update is canceled from hawkBit side, the next time the devices polls the backend, the link to the cancelAction is exposed. After GETing the cancelAction/{id}, the device confirms, that it canceled the update by POSTing cancelAction/{id}/feedback with "execution":"closed" the update action is also closed on hawkBit side.

[Second Interaction] On the other hand, if the device initiates the cancellation, it POSTs "execution":"canceled"to /deploymentBase/{id}/feedback. Followed by, a POST to the same resource with "execution":"closed", indicating the backend that the device is finished with this action.