Comprendi stato attività Rivya, prenotazione crediti, invio ai provider, callback, polling, cronologia, notifiche, errori e crediti.

Usa questa guida quando devi capire che cosa succede dopo l'invio di un'attività di generazione immagine, video o audio in Rivya.

Spiega in un unico posto stati delle attività, prenotazione crediti, completamento del provider, cronologia, notifiche e gestione delle attività fallite.

Gli stati reali delle attività

Il ciclo di vita attuale della generazione asincrona usa quattro stati visibili:

WAITING
GENERATING
SUCCESS
FAILED

Questi stati sono salvati su ai_task e riutilizzati tra Studio, cronologia, dashboard e flusso notifiche.

Cosa succede quando invii

1. Rivya valida la richiesta

Prima che qualcosa raggiunga un provider, Rivya controlla:

il modello esiste
la generazione diretta è abilitata per quel modello
l'ambiente di esecuzione è basato su attività asincrone
la lunghezza del prompt è valida
i parametri del modulo sono normalizzati
i file di riferimento corrispondono a ciò che il modello accetta

Alcuni modelli hanno regole extra. Per esempio, l'isolamento audio richiede un file audio caricato più verifica della durata.

2. Rivya crea il record dell'attività

Rivya crea prima una voce ai_task, con stato WAITING.

Quel record salva modello, categoria, prompt, params, crediti prenotati, tipo di fatturazione e poi risultato o stato di errore.

3. I crediti vengono consumati prima dell'invio al provider

Questo è importante: per la generazione asincrona, Rivya spende i crediti dell'attività prima di inviare il lavoro al servizio a monte.

Se i crediti sono troppo bassi:

l'attività viene marcata come fallita
il servizio a monte non viene mai chiamato
può essere creata una notifica di crediti insufficienti

4. Viene creato il lavoro del provider

Se i crediti sono disponibili, Rivya invia l'attività al servizio a monte corrispondente e salva l'ID attività a monte.

A quel punto lo stato passa a GENERATING.

Come Rivya apprende il risultato

Rivya supporta due percorsi di completamento:

callback del provider in ambienti con callback abilitate
refresh dello stato e polling quando il completamento via callback non è disponibile

Il percorso callback verifica anche la firma del webhook prima di finalizzare un'attività.

Se una callback arriva prima che il risultato del provider sia completamente pronto, Rivya può rinviare e riprovare controllando lo stato a monte.

Percorso di successo

In caso di successo, Rivya:

salva gli URL dei risultati
imposta lo stato su SUCCESS
regola l'attività
rende l'output disponibile nella cronologia delle generazioni
crea una notifica di generazione riuscita

Ecco perché un'immagine o un video finito resta visibile dopo che lasci la pagina.

Percorso di errore

In caso di errore, Rivya:

salva il messaggio di errore
imposta lo stato su FAILED
rimborsa i crediti quando l'errore è avvenuto dopo la prenotazione e dovrebbe essere stornato
crea una notifica di generazione fallita per revisione duratura

Questo è diverso da un toast temporaneo. L'errore diventa parte del record dell'account.

Dove vedi lo stato dell'attività

La stessa attività può comparire in più posti:

nello Studio attivo mentre è in esecuzione
in Cronologia dopo la chiusura
nel Centro notifiche per gli esiti principali
in /dashboard nelle generazioni recenti

Questo stato condiviso è uno dei motivi per cui il prodotto sembra coerente invece che usa e getta.

In cosa la chat è diversa

Anche la chat è fatturabile, ma non usa lo stesso record attività asincrono. I turni chat vengono salvati come:

sessioni chat
messaggi chat

Per i modelli chat basati su token, Rivya può prenotare prima i crediti e poi regolare l'importo finale dopo il ritorno dell'uso. Se l'importo finale è più basso, la differenza viene rimborsata.

Quindi la regola generale è:

generazione immagine, video e audio usano ai_task
la chat usa sessioni salvate e regolazione a livello di messaggio

Leggi dopo

Lista di controllo dello stato attività

Quando una generazione è confusa, lenta, fallita o mancante, controlla:

Identifica prima il tipo di attività: regolazione chat, immagine, video, audio o chat sostenuta da strumenti.
Controlla se i crediti sono stati prenotati prima dell'invio al provider o regolati dopo l'uso.
Cerca callback del provider, risultato del polling, elemento di cronologia e notifica prima di presumere che il risultato sia perso.
Separa errori correggibili dall'utente da errori del provider o dell'infrastruttura.
Conferma se un'attività fallita dovrebbe stornare crediti prima di rieseguire lo stesso prompt.

Ricontrolla prima di eseguire di nuovo

Ricontrolla quando lo stesso prompt continua a fallire, un'attività resta in corso troppo a lungo, i crediti sembrano consumati senza output o stai per inviare un'esecuzione duplicata più pesante.

Guida Rivya al ciclo di vita delle attività