Supervisor response for v2/applications/state is incorrect

Product support
1

I am trying from within my application to detect if an application update/download is in progress.
I am using pinned releases. And I have delta-updates enabled.

The /v2/applications/state supervisor API does not report the correct state it seems.

When I pin the device to a later release, it works as expected, the status object says ‘Downloading’ and the progress number grows:

{u’status’: u’Downloading’, u’releaseId’: 784146, u’downloadProgress’: 8}
{u’status’: u’Downloading’, u’releaseId’: 784146, u’downloadProgress’: 22}
{u’status’: u’Downloading’, u’releaseId’: 784146, u’downloadProgress’: 35}

However if I pin a device to an older release, the status object remains unaffected:

{u’status’: u’Running’, u’releaseId’: 784146, u’downloadProgress’: None}

… until the application suddenly reboots:

4

Could you please give us the link to a device in this state, as well as giving support access to the same device? If you had a development device that we could pin different releases on, that would be awesome.
Be wary though that this might be due to the fact that the download happens fast enough to not trigger any status update on your end, but we would like to investigate anyway.

5

To expand on @thundron’s explanation, “the download happens fast enough” may also mean that a download isn’t required at all because the device already has the required docker image layers in its local cache. You may try to verify whether this is the case by running the following commands on a host OS terminal before and after pinning the device to an older release:
balena-engine image ls -a
balena-engine history <imageID> - for the image ID of the relevant app release

If the relevant image IDs are the same before and after changing the release, no download was necessary. @krix, to clarify, other than missing ‘downloadProgress’ updates, do you mean that everything else happens as expected?

6

Thanks for your quick input, I have not had the time before now to move on with this.
I cannot make your explanation match with what I see. If the image was already there, the sw change to the older release should be really fast shouldn’t it? But it takes several minutes and the balena log contains a number of "Downloading delta for image… " messages.

Here is the requested output before and after pinning to the older release:

root@mydevice:~# balena-engine image ls -a
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
<none>                    <none>              ae569e161f70        26 minutes ago      18B
balena/amd64-supervisor   v9.0.1              691733ca7751        2 months ago        44.5MB
root@mydevice:~# balena-engine history ae569e161f70
IMAGE               CREATED             CREATED BY          SIZE                COMMENT

root@mydevice:~# balena-engine image ls -a
REPOSITORY                TAG                 IMAGE ID            CREATED              SIZE
<none>                    <none>              1789ac240fb5        About a minute ago   18B
balena/amd64-supervisor   v9.0.1              691733ca7751        2 months ago         44.5MB
root@mydevice:~# balena-engine history 1789ac240fb5
IMAGE               CREATED             CREATED BY          SIZE                COMMENT
7

For my purpose I have a workaround: If I query the device state through /v1/device, there is an “update_pending” flag which suits my purpose.

I still wonder why the pending update is not reflected in the response from v2/applications/state but I can get by for now.

1 Like
8

Hi there,

Just to update you, we have opened an issue to track this internally and we will let you know once this gets investigated in a bit more detail. It’s great that you found a workaround until we get this fixed.

Best Regards,
Steve