Le backoff anti-429 du refresh OAuth vivait uniquement en mémoire : chaque
redéploiement le remettait à zéro et re-sollicitait IMMÉDIATEMENT l'endpoint de
refresh rate-limité, entretenant le 429 qu'on cherche justement à laisser retomber.
Persiste backoff_until + le palier exponentiel (failures) sur /data
(claude_oauth_state.json), écriture atomique best-effort à la manière du cache
trackers. Chargé une fois par process en tête de fetch_usage, sauvé à chaque
échec et effacé à chaque succès. Un token frais court-circuite de toute façon le
backoff, donc un re-login isolé débloque immédiatement même si une fenêtre court.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le refresh token est rotatif : la chaîne se régénère seule indéfiniment tant que
le nouveau token est persisté. La reconnexion manuelle n'était requise que lorsque
cet invariant cassait. Trois correctifs :
- Refresh PROACTIF : on rafraîchit dès qu'il reste < 2h sur le token (~8h de vie)
au lieu des 2 dernières minutes. Un échec transitoire a des heures de marge avant
que l'access token meure ; la fenêtre où un kill/timeout perd le token rotatif
fraîchement rotaté passe de ~8h à quelques ms. Réglable via
MONITORINK_CLAUDE_REFRESH_LEAD_MIN (défaut 120).
- Distinction FATAL vs TRANSITOIRE : 400 invalid_grant / 401 sur l'endpoint token
-> _RefreshFatal, sans backoff ni re-soumission en boucle (évite la reuse-detection
qui révoque toute la famille). 429/5xx/réseau gardent le backoff exponentiel.
- Visibilité + auto-réparation : le cas fatal affiche "Reconnexion Claude requise"
(pas de repli cache silencieux) et l'alerte se referme seule dès qu'un token frais
réapparaît sur disque (re-login isolé), sans redémarrer le conteneur.
Timeout du POST de refresh porté à 45s (réglable, MONITORINK_CLAUDE_REFRESH_TIMEOUT)
pour réduire la fenêtre de perte du token après rotation serveur.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nouveau module integrations/trackers.py : pour chaque tracker configuré (env
MONITORINK_TRACKERS + bloc par clé), récupère ratio/uploaded/downloaded. Type
unit3d_nuxt (c411) : login session (CSRF meta + /api/auth/login) car le ratio
n'est pas lisible au token API ; session réutilisée, résultat caché (TTL 30 min).
Section dashboard sous le NAS, style instrument 1-bit. Architecture par type pour
ajouter d'autres trackers ensuite.
Le bind-mount d'un fichier unique reste accroché à l'inode capturé au
démarrage ; Hermes réécrit auth.json par rename atomique -> le conteneur
servait un token périmé (401), la section Codex disparaissait au refresh.
Le full refresh apparaissait trop souvent: getbbox() renvoyait un seul
rectangle englobant tous les pixels modifiés, donc météo (haut) + heure de
MaJ (ailleurs) qui changeaient au même cycle produisaient un rectangle
quasi plein écran -> ratio > partial_max_ratio -> full forcé.
- frame.py: détection des bandes horizontales modifiées disjointes
(_changed_regions), refresh partiel serré par zone. Full basé sur le
temps écoulé (last_full_at + time.monotonic) au lieu d'un compteur de
cycles. État pngs/regions en liste, get_png(client, region).
- config.py: full_refresh_interval_minutes (MONITORINK_FULL_INTERVAL_MIN,
défaut 120). Suppression de partial_max_ratio.
- app.py: /frame.meta renvoie un bloc multi-ligne "MODE SEQ N" + N régions
"i x y w h"; /frame.png?region=i.
- monitorinkloop.sh: display_meta parse le bloc et fait N fbink partiels.
Backend : endpoints /frame.meta (ligne 'MODE X Y W H SEQ') + /frame.png qui
servent un crop de la zone modifiée (diff PIL par client) ou l'image pleine.
Full refresh forcé tous les N cycles (MONITORINK_FULL_EVERY=12, ~1h) ou si la
zone change sur plus de 60% de l'écran. Mode 'noop' quand rien ne change.
Anti-429 : l'usage Claude est mis en cache (MONITORINK_USAGE_TTL=120s) avec
repli sur la dernière valeur connue en cas d'erreur transitoire.
Kobo : monitorinkloop.sh récupère meta puis png et fait un fbink partiel
(-g file=,x=,y=) sans flash, full refresh (-c -f) en mode full. Refresh 5 min.
