Disk Usage Stuck
-
As of today, the Disk Usage under System Info never stops the spinner to show the results. In the browser's network debug tab, the api call completes as 304 Not Modified and has a lot of data in the response. In the console there is an error in the angular code TypeError: Cannot read properties of undefined (reading 'name')
So it seems the Disk Usage UI was expecting a value that was not there. Of course, the console error could be from something else and not the Disk Usage. -
@Recliner2042 If you hold CTRL+F5 to force a cache refresh, does it update?
-
@murgero That did not help.
But, I did some more debugging. I see in the code that it is indeed looking for the volume name.
See https://git.cloudron.io/cloudron/box/-/blob/master/dashboard/src/views/system.js?ref_type=heads for the context of that code.And in the API the volume name is not coming through.
-
Possibly related. I have these 2 ghost volumes. By that I mean I had properly removed them but they are still listed.
Including those two ghosted volumes, I have a total of 4 volumes (not all in the same disk) and all are missing the
name
field.But on the Volumes screen, the names do come through. It is only on the Disk Usage screen that they don't. (also the ghost volumes don't show on the Volumes screen)
-
@Recliner2042 said in Disk Usage Stuck:
Including those two ghosted volumes, I have a total of 4 volumes (not all in the same disk) and all are missing the
name
field.After reading the code closer, I see that the name field is not actually supposed to be there in the API call. It finds the name from the volume map from the volumes api call.
But the 2 ghosted volumes, are not returned by the volume api call.
(above: only the two valid volumes returned by volumes call)And so their name can't be found when they are looped over after the disk_usage api call.
So the question is: why is the disk_usage API call picking up ghost volumes that the volumes API call is not picking up?
-
So the problem is that the disk usage data is still cached in a file (https://git.cloudron.io/cloudron/box/-/blob/master/src/system.js?ref_type=heads line 260) from checking before the 2 ghost volumes were removed.
So simply forcing a recheck should fix it. But that can't be done because the button is disabled.
So I force enabled the button in my browser, clicked it, and now it is working fine.
So the issue seems to be, that the cache file is not invalidated when a volume is removed. (maybe it is normally but failed for me)
For a simple solution, I would propose enabling the recheck button as soon as the api call returns before executing the handling of the data. So that way if there is an error processing the data, the button is enabled.
See https://git.cloudron.io/cloudron/box/-/blob/master/dashboard/src/views/system.js?ref_type=headsOf course check into the disk usage cache file invalidation, too. I assume that "normally" when you remove a volume, the file is invalidated. But there seems to be an edge case where it does not always.
Edit: I just had a look over volumes.js and mounts.js and it look like the cache file is never invalidated by the del/remove action.
-
@girish I'm pinging you because the git history shows you as the main author of all the code files involved.
-
@Recliner2042 the disk usage is not instantaneous. It runs in a background task periodically. There is a refresh button on top of the disk usage graphs. If you click that, then it will collect the disk usage afresh. You can also see the logs of the task there. It's expected that the cache is not invalidated when volumes are removed etc.
-
@girish When the cache is invalid, it causes a runtime error, and the error prevents the refresh button from getting enabled. I'm asking for the refresh button to immediately enable in the handler, so if there is an error in the handler from invalid data, one may still click the refresh button.
-
-
@Recliner2042 ah fair, that's a bug then. Can you contact us at support@cloudron.io , so we can debug this further?
-