[ADU] ESP32 ADU sample freezes when downgrading the image (1.1 to 1.0) about iot-middleware-freertos-samples HOT 4 CLOSED

Repro:

1. I followed steps to create an v1.0 image using ESP-IDF and flashed my device. Before doing anything else, I also created an ADU update for this image.
2. I then created a v1.1 image and also created an ADU update for this.
3. I imported both v1.0 and v1.1 to ADU
4. ADU tells me the latest update for that device is v1.1, as expected, and I deployed that to the device. The device successful reports v1.1 and ADU also says it was successful.
5. Go to ADU and delete v1.1 update
6. ADU will eventually show that the latest update should be v1.0, and let you deploy it. Create a new deployment.

At this point, the device is stuck. ADU reports the update is available, but never says it is in progress. I see no new messages generated on the console for the device. If I look at the device twin, it says the connection state is "disconnected".

Following our in-person debugging, I pressed the reset button on the device. When the device reset, it started to pick up the v1.0 update, and at that point everything proceeded as expected (console reports v1.0 installed, and ADU says it is installed). As far as I can tell, it looks right at this point, and there is a bug requiring me to reboot the device.

FWIW, you guys noticed this in my console log after the device was reset, that seems like it might be a related issue?

E (195671) AZ IOT: az_iot_adu_client_get_agent_state_payload failed: 0x80010002
E (195671) AZ IOT: [ADU] Failed sending agent state.

from iot-middleware-freertos-samples.

I have a strong suspicion it is because the sample is receiving the following in the desired properties:

"desired": {
"deviceUpdate": {
"service": {
"workflow": {
"action": 255,
"id": "nodeployment"
}
},
"__t": "c"
},
"$version": 4
}

Deleting an update in the portal causes this. It was discussed previously that when an update is deleted in the portal, ADU should not write "nodeployment", it should write the id of the deleted update.

from iot-middleware-freertos-samples.

But in any case, our code should handle that, so we need to fix it too.

from iot-middleware-freertos-samples.

The root of the problem comes with this payload being parsed

{
  "service": {
    "workflow": {
      "action": 255,
      "id": "nodeployment"
    }
  },
  "__t": "c"
}

And the problematic code is here:

It should not get to line 312 as there is no update manifest.

We should maybe check the action or the id for nodeployment.

from iot-middleware-freertos-samples.