[Bloquant v1.0] `_parse_bucket_ts` : `datetime.fromtimestamp` non gardé peut tuer tout le cycle de poll pendant des jours #78

New issue

Open

opened 2026-08-26 05:31:52 +00:00 by mat · 0 comments

mat commented

2026-08-26 05:31:52 +00:00

Owner

Problème

Dans _parse_bucket_ts (custom_components/comwatt/coordinator.py:113-116), la branche numérique appelle datetime.fromtimestamp(ts, tz=UTC) sans try/except, alors que le contrat de la fonction est de retourner None pour toute valeur non parsable. Une epoch en microsecondes, une valeur aberrante (1e15) ou une chaîne numérique délirante ("99999999999999999999" via int(s) lignes 113-114) lève OverflowError/ValueError/OSError.

Les appelants (coordinator.py:568 côté site, coordinator.py:809 côté device) ne protègent pas l'appel : l'exception remonte jusqu'au except Exception global de _async_update_data → UpdateFailed.

Risque

Tous les capteurs passent indisponibles à chaque poll, pendant toute la durée où la valeur fautive reste dans la fenêtre de requête (8 jours côté site, 24 h côté device). L'intégration est morte pendant des jours à cause d'une seule valeur aberrante de l'API.

Recommandation

Envelopper datetime.fromtimestamp dans try/except (ValueError, OverflowError, OSError) → return None.
Étendre le except du datetime.fromisoformat (ligne 126-128) à TypeError.
Ajouter des tests unitaires : epoch µs, année > 9999, epoch négative géante.

Constaté lors de la review de code pré-v1.0 (v0.8.1).

## Problème Dans `_parse_bucket_ts` (`custom_components/comwatt/coordinator.py:113-116`), la branche numérique appelle `datetime.fromtimestamp(ts, tz=UTC)` **sans try/except**, alors que le contrat de la fonction est de retourner `None` pour toute valeur non parsable. Une epoch en microsecondes, une valeur aberrante (`1e15`) ou une chaîne numérique délirante (`"99999999999999999999"` via `int(s)` lignes 113-114) lève `OverflowError`/`ValueError`/`OSError`. Les appelants (`coordinator.py:568` côté site, `coordinator.py:809` côté device) ne protègent pas l'appel : l'exception remonte jusqu'au `except Exception` global de `_async_update_data` → `UpdateFailed`. ## Risque **Tous les capteurs passent indisponibles** à chaque poll, pendant toute la durée où la valeur fautive reste dans la fenêtre de requête (8 jours côté site, 24 h côté device). L'intégration est morte pendant des jours à cause d'une seule valeur aberrante de l'API. ## Recommandation 1. Envelopper `datetime.fromtimestamp` dans `try/except (ValueError, OverflowError, OSError) → return None`. 2. Étendre le `except` du `datetime.fromisoformat` (ligne 126-128) à `TypeError`. 3. Ajouter des tests unitaires : epoch µs, année > 9999, epoch négative géante. --- Constaté lors de la review de code pré-v1.0 (v0.8.1).

mat added the

v1.0 · bloquant

label

2026-08-26 05:31:52 +00:00

No labels

v1.0 · bloquant

v1.0 · majeur

v1.0 · mineur

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

mat/homeassistant-comwatt#78

No description provided.

Rows
Columns

[Bloquant v1.0] _parse_bucket_ts : datetime.fromtimestamp non gardé peut tuer tout le cycle de poll pendant des jours #78

Problème

Risque

Recommandation

[Bloquant v1.0] `_parse_bucket_ts` : `datetime.fromtimestamp` non gardé peut tuer tout le cycle de poll pendant des jours #78