Two (legacy?) bugs

Attempting to perform a container update fails (e.g change an env var) state is eventually in sync when the device queries the API. When troubleshooting I see the issue:

02:52:47.628462 IP 52.4.252.97.45211 > 10.240.24.217.48484: Flags [P.], seq 1:389, ack 1, win 502, options [nop,nop,TS val 2164788653 ecr 2866573106], length 388
E.....@....E4..a
......d......
x....V......
......o2POST /v1/update?apikey=REMOVEDHTTP/1.1
host: REMOVED.balena:48484
content-length: 0
sentry-trace: c1a85d87c13905a7d3939da6506d0885-f025dbd275cefd2a
baggage: sentry-environment=production,sentry-release=82.18.12,sentry-public_key=REMOVED,sentry-trace_id=c1a85d87c13905a7d3939da6506d0885
Connection: close


02:52:47.628644 IP 10.240.24.217.48484 > 52.4.252.97.45211: Flags [.], ack 389, win 857, options [nop,nop,TS val 2866573450 ecr 2164788653], length 0
E..4E.@.@...
...4..a.d....
x...}...Y-......
..p....
02:52:47.831997 IP 10.240.24.217.48484 > 52.4.252.97.45211: Flags [P.], seq 1:287, ack 389, win 857, options [nop,nop,TS val 2866573653 ecr 2164788653], length 286
E..RE.@.@...
...4..a.d....
x...}...Y.......
..qU....HTTP/1.1 503 Service Unavailable
Content-Type: application/json; charset=utf-8
Content-Length: 85
ETag: W/"55-tt/tIuAlRrQZdMEAD8xbBQwnB7o"
Date: Fri, 29 Nov 2024 02:52:47 GMT
Connection: close

{"status":"failed","message":"Cannot read properties of undefined (reading 'force')"}
  1. Its currently not possible to convert legacy devices to classic (its been this way for years). You can click the link but the device remains legacy.

Hi,
Can you clarify what OS & supervisor version is your device running?
Can you give an exact example of what you mean as a container update? For example are you trying to set an env var via the device environment variables page?
Can you also provide a screenshot from what you see on our dashboard?
In general switching Legacy fleets to Classic is allowed, but it’s necessary that all devices of the fleet to be running at least balenaOS v2.0.3.

  1. The OS and supervisor version is not relevant to the request generated by your balena cloud end. However we are running supervisor v16.7.7 and balenaOS 6.0.25 .

  2. Any variable or container change that triggers /v1/update I diagnosed the issue using environment variables. We patched our supervisor build to work to work around your issue in the mean time (https://img.x4b.org/2024-12/GitHubDesktop_2024-12-02_11-36-36.png)

  3. You can click this (https://img.x4b.org/2024-12/chrome_2024-12-02_11-33-58.png) and follow the process until its “sucessful” (as per the toast) however it never actaully does it. It’s still a legacy fleet. Its been this way for at-least a year (its been a non issue for us and we figured you would recognise the issue and fix it at some point).

Hi,
Do you mean that even using dashboard.balena-cloud.com to set a fleet variable leads to this error on your devices? Also, do you face this issue on all devices of your fleet?

Unfortunately I wasn’t able to reproduce the issue on my side. I created a new legacy RaspberryPi3 fleet and provisioned a device with balenaOS 6.0.23. I was then able to create a fleet environment variable from the dashboard’s page and was able to see the hournalctl logs on the device report that it was properly picked up:

Would you mind opening a pull request with your fix on our balena-supervisor repository so that you also get the credits for it?

This is not a fix that should be made in supervisor!

Thats a balena cloud bug, look at the provided tcpdump (there is no body). All I have implemented is a workaround.