Ciclo di vita della sessione di registrazione
Una sessione di registrazione è un singolo tentativo di registrazione da start a stop. La sessione esiste anche se gli artefatti finali non sono caricabili.
Contratto del ciclo di vita
Ogni sessione dovrebbe avere:
- Un evento di start quando la registrazione comincia.
- Un evento terminale quando la registrazione si ferma, fallisce, viene auto-messa-in-pausa o viene altrimenti abbandonata.
- Un risultato di validazione dopo che gli artefatti locali sono stati chiusi.
- Record di upload solo quando il risultato della validazione locale è caricabile.
Lo stato terminale deve essere esplicito. Se una sessione si interrompe a metà, il core deve comunque emettere un risultato terminale con uno status di fallimento e una ragione granulare.
Panoramica del ciclo di vita
Entità attuali
| Layer | Responsabilità |
|---|---|
| Core | Possiede la capture, il muxing, la validazione locale, la generazione dei metadata, il gating degli upload e la telemetria del ciclo di vita. |
| UI | Mostra lo stato corrente di registrazione, lo storico delle sessioni, l'uploadability e le ragioni di fallimento. |
| SQLite locale | Memorizza lo storico delle sessioni locali e abbastanza stato diagnostico per spiegare perché una sessione era uploadable o bloccata. |
| Supabase | Memorizza i record normalizzati lato server di sessioni e upload per tester, monitoraggio e KPI per gli investitori. |
| Lambda / upload presigned | Accetta l'intent di upload e fornisce destinazioni S3 per gli artefatti validati. |
Stati attesi
| Stato | Significato |
|---|---|
recording | La capture è attiva o temporaneamente in pausa nella stessa sessione. |
stopping | Il core sta chiudendo capture, muxing, metadata e validazione. |
uploadable | MP4, CSV e JSON hanno superato la validazione e possono essere caricati come tripletta coerente. |
blocked | La sessione si è completata localmente ma ha fallito la validazione. Nessun upload parziale deve partire. |
failed | La sessione non si è completata normalmente, ma serve comunque un record terminale con la ragione. |
uploaded | Tutti gli artefatti richiesti sono stati caricati e lo stato server è coerente. |
Invarianti
- Una sessione è l'unità di pagamento e di indagine support.
- Le ore di registrazione devono provenire dal timing validato della sessione, non da conteggi di upload best-effort.
- L'upload deve essere all-or-nothing per la tripletta di artefatti richiesti.
- La tripletta richiesta oggi è MP4, CSV e JSON.
- OGG è legacy e non dovrebbe comparire nei nuovi flussi di registrazione pure-v2.
- I dati di lobby sono metadata opzionali usati per accoppiare sessioni simultanee; non sono l'identità della sessione.
Lavoro aperto
- Garantire che lo storico UI mostri le sessioni bloccate e fallite con ragioni granulari.
- Garantire che Supabase
recording_sessionsmemorizzi lo status terminale di validazione/upload e la ragione di fallimento. - Allineare i nomi dei campi tra core, UI, SQLite, Supabase e codice di upload.