Il contesto
Creators Pro coordina il lavoro delle creator e dei team che ne gestiscono la produzione di contenuti. Il team assegna task e segue editing, approvazione e pubblicazione; le creator ricevono le richieste nell’app iOS e caricano foto e video.
Ho lavorato alla costruzione e all’evoluzione del flusso di upload: selezione dei media, gestione dei formati nativi e delle risorse iCloud, avanzamento e caricamento in background. Nel tempo il sistema è passato dalle integrazioni con Google Drive e Airtable al trasferimento su Google Cloud Storage tramite URL firmati.
Il problema
Il trasferimento del file e l’aggiornamento del suo stato applicativo avvenivano in momenti diversi. Dopo l’arrivo del file nello storage, un evento Pub/Sub doveva essere elaborato dal backend per attivare il contenuto nel database.
In alcuni casi il file era presente, ma quell’aggiornamento non veniva completato. Ho seguito la diagnosi, gli interventi sulla soluzione, la verifica del comportamento e il recupero dei contenuti, lavorando anche in pair programming.
La diagnosi
Ho migliorato i messaggi inviati a Sentry e analizzato i log per ricostruire il percorso degli eventi.
Il problema coinvolgeva ambienti con versioni differenti del codice: processi locali potevano ricevere messaggi della stessa subscription usata dal sistema atteso. L’elaborazione poteva quindi terminare senza completare l’attivazione del contenuto nel database corretto.
Gli interventi hanno riguardato la configurazione delle subscription per ambiente e la gestione degli errori durante l’elaborazione. Una parte importante era far arrivare gli errori operativi fino al listener, così che un’elaborazione fallita potesse richiedere un nuovo tentativo.
Dal recupero manuale alle API di debug
Inizialmente recuperavo manualmente i contenuti rimasti non attivi. Con il ripresentarsi del problema e l’accumulo dei casi, ho introdotto API dedicate per ispezionare gli stati e correggerli in modo controllato.
Gli strumenti permettevano di individuare i casi per stato e periodo, selezionare gli ID da trattare e limitare il numero di elementi aggiornati in una chiamata. Il riepilogo distingueva i contenuti aggiornati da quelli già completati, mancanti o non idonei.
Ho poi aggiunto un controllo opzionale sulla presenza del file originale nel bucket prima dell’attivazione. Con il controllo abilitato, i file mancanti e le verifiche fallite venivano saltati e riportati nella risposta.
Ho utilizzato personalmente queste API per recuperare i contenuti e le ho migliorate in più occasioni. Erano strumenti operativi usati da me durante la manutenzione del sistema.
Il risultato
Ho recuperato i contenuti rimasti non attivi e costruito una procedura riutilizzabile per gestire i casi successivi. Le informazioni raccolte in Sentry e nei log hanno supportato la diagnosi; le API hanno dato una struttura al lavoro di recupero che svolgevo manualmente.
Approfondimento tecnico
Il diagramma rappresenta i passaggi logici del caso e il percorso di recupero operativo.
- Selezione e preparazione su iOS
- File nello storage
- Evento Pub/Sub
- Elaborazione backend
- Stato aggiornato nel database
Record non attivo → ispezione e recupero tramite API di debug → aggiornamento controllato dello stato.
Conferma degli eventi
Il listener conferma il messaggio dopo il ritorno dell’handler. Gli errori operativi devono propagarsi fino al listener per consentire una conferma negativa e un nuovo tentativo. La configurazione della subscription stabilisce invece quali eventi riceve ciascun ambiente.
Perimetro del recupero
Le API descritte lavoravano su ID espliciti, fino a 100 per chiamata, e applicavano controlli sull’organizzazione del chiamante e sull’idoneità dei record. Gli aggiornamenti riguardavano media sorgente non eliminati ed escludevano quelli già completati.
Controllo del file
L’opzione di verifica del bucket accertava la presenza del file originale. La validità del contenuto e l’eventuale copia su Google Drive erano controlli distinti. Questo strumento gestiva i casi rimasti bloccati, mentre gli interventi su configurazione ed elaborazione degli eventi affrontavano la causa.