Device showing old commit ID after moving to a different application

Hi everyone,

I’m currently testing the possibility of changing the running application on an existing device (while using OpenBalena as device manager).

Let’s say I have two applications – app_A and app_B – and my device is running app_A.
If I try to move it to app_B using the balena CLI (i.e. by using balena device move <device_uuid>) everything seems to work fine, since I can access the services exposed by app_B.

However, while checking the device info (i.e. by using balena device <device_uuid>) after the application switch, I noticed that the commit ID does not seem to update accordingly.
In fact, the output from the aforementioned command gives me something like:

APPLICATION NAME: app_B
[…]
COMMIT: <latest-app_A-commit>

I also tried to edit app_B containers in order to be able to deploy newer versions of app_B to my device, but that led me to the same result (i.e. device runs the latest version of app_B, but commit ID still refers to the latest version of app_A).

Interestingly, moving back to app_A by following the same procedure (i.e. balena device move <device_uuid>) and then deploying a newer version of app_A to the device seems to correcly update the commit ID.

Am I missing something about the “move” procedure between two applications? How can I make the commit ID change to its correct value whenever I switch to app_B?

Here’s some details about my current setup:

Balena CLI version: 12.44.10
OpenBalena version: 3.2.1
Device OS version: 2.71.5+rev6
Device supervisor version: 12.6.2

Please feel free to ask for further details about my Balena setup if needed.

Hey there, what an interesting issue! Is the balena device command the only place where the application A commit is still shown, or is it somewhere in the Dashboard UI as well?

I’m going to see if I can reproduce this internally and we’ll get back to you!

Hey, you can disregard the question about the dashboard, I forgot you were using openBalena!

We may be tracking a similar issue internally but it’s been difficult to reproduce. Would you be willing to help us collect some additional information so we can debug this further?
For starters, the supervisor logs from the device after it has fully moved to Application B would be helpful. You can collect those on the host OS with journalctl -u resin-supervisor --no-pager.

Also, I don’t know if you’ve used our SDK before but if you could try running the following queries we could look for differences in the current state vs the target state after it’s been moved fully to Application B.

balena.models.device.getSupervisorState('<UUID>', function(error, state) {
    if (error) throw error;
    console.log(state);
});
balena.models.device.getSupervisorTargetState('<UUID>', function(error, state) {
    if (error) throw error;
    console.log(state);
});

Let us know if you need assistance getting the SDK up and running or if any of the steps are unclear!

Hey @ngmb Did you get chance to try the suggestion from Klutchell? Let us know if you still need assistance with this :slight_smile:

Hey @klutchell and @Jazzagi, thank you for your replies!

Unfortunately, I can’t reproduce the issue anymore (using the same setup I mentioned in my first post). The commit ID seems to correctly change now, and I honestly have no clue of what might have happened during my first experiment.
I’ll surely update this thread with the info @klutchell requested if the issue occurs again in the future.

Thank you for your time!