Vai al contenuto

MDM-030 · Riportare in stage i comportamenti della 3.2.9

Campo Valore
Gruppo 2 · Codice box e wrapper
Assegnato a (proposta) Lorenzo
Priorità P1
Stima indicativa M
Stato 🔄 in corso
Attività del piano T2.1
Dipende da —

Contesto

42 commit solo su main, analizzati il 29/10/2026: fix-main-da-portare-in-stage.md. 18 sono solo versioni e tag; diversi comportamenti sono già presenti in stage, scritti in altro modo. Restano quattro comportamenti da riscrivere in stage (non si possono riportare con un cherry-pick, la struttura è diversa).

Cosa fare

  • [x] Classificare i 42 commit (29/10/2026).
  • [x] Sincronizzazione telecamere leggera (29/10, sulla stage, commit f427d22e): una sola chiamata al detector, nessuno snapshot; controllo anti-manomissione attuale disattivato (SIFT tolto); damage resta nello stato. Test: tests/test_app/test_services/test_camera_manager/, suite completa 654 verdi.
  • [x] Database: rollback su ogni scrittura fallita, rilascio della sessione dopo richieste e cicli (337fe08d, e24b47d2); in più ErrorLogs non solleva mai e il ciclo di monitoraggio non può morire (29/10, sulla stage, commit b9dd8510; test con database bloccato, suite 692 verdi; sessione rilasciata anche nell'autenticazione, che gira nel pool di thread).
  • [x] /status: chiamate di controllo con un solo tentativo, pausa di 10 s verso un servizio che non risponde senza riempire valori vecchi, cache di 2 s con un solo calcolo alla volta, calcolo fuori dal loop di FastAPI (8f29f6d3, e24b47d2, 413c6e40; 29/10, sulla stage, commit d567c9e7; suite 706 verdi).
  • [x] Prove sul box di test GANZ (30/10): /status, GANZ irraggiungibile, avvio con il GANZ irraggiungibile, divergenza arm_state; corretti l'avvio (controlli delle telecamere creati quando il detector risponde), la copia dello stato del GANZ (DISARMSTATUS) e la lettura degli ingressi di allarme con i retry. Dettagli in fix-main-da-portare-in-stage.md.
  • [x] Eventi che restavano in coda per sempre senza notification provider (solo Telegram; la consegna al midserver è via MQTT e non cambia) configurato: "nessun provider" vale "niente da consegnare" (30/10, commit ebde226c, verificato sul box di test).
  • [ ] Togliere il provider Telegram quando si decide (il codice in event_manager/notif_provider e la parte "provider" della coda).
  • [ ] /heartbeat: lavoro bloccante in una route async (sincronizzazione telecamere, sync_to_server con i 10 retry del client del midserver).
  • [x] Stato inserito/disinserito: disarm mai vuoto (stato salvato dal box, dichiarato come tale, quando il detector non si legge); 503 dopo 60 s senza raggiungere il wrapper; online da una sola fonte; avvio robusto se il detector non risponde; evento arm_state quando detector e stato salvato divergono, mostrato in qAlarm (3.2.9; 29/10, sulla stage, commit a7ba5da9 e d65178d2; suite 730 verdi).
  • [x] Test per ognuno; CHANGELOG.md della stage (sezione Unreleased, fino al commit ebde226c del 30/10).

Criteri di accettazione

  • Su un box di prova stage, con il wrapper riavviato a mano, /status non riporta mai lo stato vuoto e risponde in meno di 1 s.
  • Un errore di scrittura simulato sul database non blocca le operazioni successive.
  • CPU del box stage con 8+ telecamere confrontabile con quella della 3.2.9.

Rischi e attenzioni

Nessun impatto sul parco finché non si rilascia. Il formato di /status è diverso tra le linee: verificare chi lo legge.

Riferimenti