Rivyas guide till uppgiftslivscykeln

Använd den här guiden när du behöver förstå vad som händer efter att du skickar in en bild-, video- eller ljudgenereringsuppgift i Rivya.

Den förklarar uppgiftsstatus, kreditreservering, leverantörens slutförande, historik, aviseringar och hantering av misslyckade uppgifter på ett ställe.

De verkliga uppgiftsstatusarna

Den nuvarande asynkrona genereringslivscykeln använder fyra synliga statusar:

• WAITING

• GENERATING

• SUCCESS

• FAILED

De här statusarna lagras på ai_task och återanvänds i Studio-, historik-, dashboard- och aviseringsflödet.

Vad som händer när du skickar in

1. Rivya validerar förfrågan

Innan något når en leverantör kontrollerar Rivya:

• att modellen finns

• att direct generation är aktiverad för den modellen

• att runtime är async-uppgift-baserad

• att promptlängden är giltig

• att formulärparametrar normaliseras

• att referensfiler matchar vad modellen accepterar

Vissa modeller har extra regler. Till exempel kräver ljudisolering en uppladdad ljudfil plus längdverifiering.

2. Rivya skapar uppgift record

Rivya skapar först en ai_task-post med statusen WAITING.

Den posten lagrar modell, kategori, prompt, parametrar, reserverade credits, faktureringstyp och senare resultat- eller felstatus.

3. Credits förbrukas före leverantörsinlämning

Det här är viktigt: för async generation spenderar Rivya uppgift credits innan jobbet skickas upstream.

Om credits är för låga:

• markeras uppgiften som misslyckad

• upstream-tjänsten anropas aldrig

• en avisering om otillräckliga credits kan skapas

4. Leverantörsjobbet skapas

Om credits finns tillgängliga skickar Rivya uppgiften till matchande upstream-tjänst och lagrar upstream uppgift ID.

Vid den punkten går status till GENERATING.

Hur Rivya får veta resultatet

Rivya stöder två vägar för slutförande:

• leverantörscallback i miljöer där callbacks är aktiverade

• statusuppdatering och polling när callback-slutförande inte är tillgängligt

Callback-vägen verifierar också webhook-signaturen innan en uppgift finaliseras.

Om en callback kommer innan leverantörsresultatet är helt klart kan Rivya skjuta upp och försöka igen genom att kontrollera upstream-status.

Vägen vid lyckat resultat

Vid lyckat resultat gör Rivya detta:

• lagrar resultat-URL:er

• sätter status till SUCCESS

• avräknar uppgiften

• gör resultatet tillgänglig i genereringshistorik

• skapar en avisering om lyckad generering

Därför förblir en färdig bild eller video synlig efter att du lämnar sidan.

Vägen vid fel

Vid fel gör Rivya detta:

• lagrar felmeddelande

• sätter status till FAILED

• återför credits när felet inträffade efter reservation och bör reverseras

• skapar en avisering om misslyckad generering för hållbar granskning

Det skiljer sig från en tillfällig toast. Felet blir en del av kontots post.

Var du ser uppgift state

Samma uppgift kan visas på flera platser:

• den aktiva Studio medan den körs

• Historik efter att den avräknas

• Aviseringscenter för större händelser

• /dashboard i senaste genereringar

Den delade statusen är en av orsakerna till att produkten känns sammanhängande i stället för tillfällig.

Hur Chat skiljer sig

Chat är också debiterbar, men använder inte samma asynkrona uppgiftspost. Chatturer lagras som:

• chattsessioner

• chattmeddelanden

För tokenbaserade chattmodeller kan Rivya först reservera credits och sedan avräkna slutbeloppet efter att användningen kommer tillbaka. Om slutbeloppet är lägre återbetalas skillnaden.

Den breda regeln är alltså:

• bild-, video- och ljudgenerering använder ai_task

• chat använder sparade sessioner och avräkning på meddelandenivå

Läs vidare

• Bildarbetsflöden i Rivya

• Videoarbetsflöden i Rivya

• Ljudarbetsflöden i Rivya

• Credits och fakturering

• Felsökning i Rivya

• Aviseringscenter

• Historik

Checklista för uppgiftsstatus

När en generering är förvirrande, långsam, misslyckad eller saknas, kontrollera:

• Identifiera uppgiftstyp först: chattavräkning, bild, video, ljud eller verktygsstödd chatt.

• Kontrollera om credits reserverades före leverantörsinlämning eller avräknades efter användning.

• Leta efter leverantörscallback, pollingresultat, historikpost och avisering innan du antar att resultatet är förlorat.

• Separera fel som användaren kan rätta från leverantörs- eller infrastrukturfel.

• Bekräfta om en misslyckad uppgift bör reversera credits innan du kör om samma prompt.

Kontrollera igen innan du kör på nytt

Kontrollera igen när samma prompt fortsätter att misslyckas, en uppgift ligger pågående för länge, credits verkar förbrukade utan resultat eller du är på väg att skicka in en tyngre dubbelkörning.