diskio API intermittently omits time_since_update, crashing the Home Assistant Glances integration (KeyError) Describe the bug

[liuk4friends]

ERROR:

Registratore: homeassistant.components.glances.coordinator
Fonte: helpers/update_coordinator.py:435
Integrazione: Glances (documentazione, problemi)
Prima occorrenza: 22:12:21 (1 occorrenza)
Ultimo accesso: 22:12:21

Unexpected error fetching glances - 192.168.178.100 data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 435, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/glances/coordinator.py", line 46, in _async_update_data
    data = await self.api.get_ha_sensor_data()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/glances_api/__init__.py", line 230, in get_ha_sensor_data
    time_since_update = disk["time_since_update"]
                        ~~~~^^^^^^^^^^^^^^^^^^^^^
KeyError: 'time_since_update'

DESCRIPTION:
The REST API (/api/4/diskio, also inside /api/4/all) intermittently returns one or more entries missing the time_since_update key. This is a documented field of the diskio plugin, and clients rely on it unconditionally — for example the Home Assistant glances-api library crashes with KeyError: 'time_since_update' at glances_api/init.py:230, which takes down the whole HA coordinator refresh (all Glances sensors become unavailable for ~1 minute).

I checked the live endpoint repeatedly: of 372 diskio entries (mostly loop0-255, dm-, nbd, md* — a QNAP with docker/snapshots), every sampled response contained time_since_update, so the omission is transient (possibly a block device appearing/disappearing mid-plugin-refresh without a previous sample). The failure recurs roughly every 10–13 minutes in my setup.

ENVIROMENT

• Glances server version: 4.5.5 (latest release, 2026-06-13) — REST mode, port 61208
• Device: QNAP TS-664 (QTS — please tell me if you need the exact QTS build)
• Client: Home Assistant Core 2026.7.4 on Home Assistant OS 18.2 (Raspberry Pi 5, 64-bit), Glances integration, bundled client glances-api 0.10.0, Python 3.14

STEPS TO REPRODUCE

1. Run Glances in server mode on a system with many/transient block devices (loop, dm-, nbd, docker).
2. Poll GET /api/4/all (or /api/4/diskio) continuously from the client.
3. Eventually a response contains a diskio entry without time_since_update.

OBSERVED BEHAVIOR
Client raises:
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 435, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/components/glances/coordinator.py", line 46, in _async_update_data
data = await self.api.get_ha_sensor_data()
File "/usr/local/lib/python3.14/site-packages/glances_api/init.py", line 230, in get_ha_sensor_data
time_since_update = disk["time_since_update"]
KeyError: 'time_since_update'

EXPECTED BEHAVIOR
time_since_update is always present for every diskio entry (or consistently omitted), so clients do not crash intermittently.

ADDITIONAL CONTEXT

• Client-side workaround would be to use the new read_bytes_rate_per_sec / write_bytes_rate_per_sec fields (present in Glances 4.5+ responses) instead of read_bytes / time_since_update. That would belong in home-assistant-ecosystem/python-glances-api, which currently still reads disk["time_since_update"] unguarded (verified on the latest commit, 2026-04-15).
• Happy to capture a full response with the missing key if you can suggest a reliable way to catch it (e.g., a debug flag or polling during a snapshot/container churn).

Please note that the text was written with the help of OpenCode 2.4.0.
I apologize for any inconvenience.