Rivyas guide til opgavelivscyklus

Brug denne guide, når du skal forstå, hvad der sker efter indsendelse af en billed-, video- eller lydgenereringsopgave i Rivya.

Den forklarer opgavetilstande, credit-reservation, provider-fuldførelse, historik, notifikationer og håndtering af fejlede opgaver ét sted.

De reelle opgavetilstande

Den aktuelle asynkrone genereringslivscyklus bruger fire synlige tilstande:

• WAITING

• GENERATING

• SUCCESS

• FAILED

Disse tilstande gemmes på ai_task og genbruges på tværs af Studio-, historik-, dashboard- og notifikationsflowet.

Hvad sker der når du indsender

1. Rivya validerer anmodningen

Før noget når en provider, tjekker Rivya:

• at modellen findes

• at direkte generering er aktiveret for den model

• at runtime er baseret på asynkrone opgaver

• at promptlængden er gyldig

• at formularparametre er normaliserede

• at referencefiler matcher det, modellen accepterer

Nogle modeller har ekstra regler. For eksempel kræver lydisolering en uploadet lydfil plus verifikation af varighed.

2. Rivya opretter opgaveposten

Rivya opretter først en ai_task-post med status WAITING.

Den post gemmer model, kategori, prompt, params, reserverede credits, faktureringstype og senere resultatet eller fejltilstanden.

3. Credits forbruges før provider-indsendelse

Dette er vigtigt: for asynkron generering bruger Rivya opgave-credits, før jobbet sendes upstream.

Hvis der er for få credits:

• markeres opgaven som fejlet

• upstream-tjenesten kaldes aldrig

• der kan oprettes en notifikation om utilstrækkelige credits

4. Provider-jobbet oprettes

Hvis der er credits til rådighed, indsender Rivya opgaven til den matchende upstream-tjeneste og gemmer upstream-opgave-ID'et.

På det tidspunkt flytter status til GENERATING.

Hvordan Rivya får resultatet

Rivya understøtter to fuldførelsesveje:

• provider-callback i miljøer, hvor callbacks er aktiveret

• statusopdatering og polling, når callback-fuldførelse ikke er tilgængelig

Callback-stien verificerer også webhook-signaturen, før en opgave færdiggøres.

Hvis et callback ankommer, før provider-resultatet er helt klar, kan Rivya udskyde og prøve igen ved at tjekke upstream-status.

Successtien

Ved succes gør Rivya følgende:

• gemmer resultat-URL'er

• sætter status til SUCCESS

• afregner opgaven

• gør outputtet tilgængeligt i genereringshistorikken

• opretter en notifikation om genereringssucces

Det er derfor, et færdigt billede eller en færdig video forbliver synlig, efter du forlader siden.

Fejlstien

Ved fejl gør Rivya følgende:

• gemmer fejlbeskeden

• sætter status til FAILED

• refunderer credits, når fejlen skete efter reservation og bør tilbageføres

• opretter en notifikation om genereringsfejl til varig gennemgang

Det er anderledes end en midlertidig toast. Fejlen bliver en del af kontoens historik.

Hvor du ser opgavetilstand

Den samme opgave kan dukke op flere steder:

• i det aktive Studio, mens den kører

• i History, efter den afregnes

• i Notifications Center ved større udfald

• på /dashboard i seneste genereringer

Den delte tilstand er en af grundene til, at produktet føles sammenhængende i stedet for engangsbaseret.

Hvordan Chat er anderledes

Chat er også fakturerbar, men den bruger ikke den samme asynkrone opgavepost. Chat-ture gemmes som:

• chatsessioner

• chatbeskeder

For tokenbaserede chatmodeller kan Rivya først reservere credits og derefter afregne det endelige beløb, når usage kommer tilbage. Hvis det endelige beløb er lavere, refunderes forskellen.

Den brede regel er derfor:

• billed-, video- og lydgenerering bruger ai_task

• chat bruger gemte sessioner og afregning på beskedniveau

Læs næste

• Billedarbejdsgange i Rivya

• Videoarbejdsgange i Rivya

• Lydarbejdsgange i Rivya

• Credits og fakturering

• Fejlfinding i Rivya

• Notifications Center

• History

Tjekliste for opgavetilstand

Når en generering er forvirrende, langsom, fejlet eller mangler, så tjek:

• Identificer først opgavetypen: chatafregning, billede, video, lyd eller værktøjsunderstøttet chat.

• Tjek, om credits blev reserveret før provider-indsendelse eller afregnet efter usage.

• Kig efter provider-callback, polling-resultat, historikpost og notifikation, før du antager, at resultatet er tabt.

• Adskil brugerrettelige fejl fra provider- eller infrastrukturfejl.

• Bekræft, om en fejlet opgave bør tilbageføre credits, før du kører den samme prompt igen.

Gentjek før du kører igen

Gentjek, når den samme prompt bliver ved med at fejle, en opgave bliver i gang for længe, credits ser ud til at være brugt uden output, eller du er ved at indsende en tungere dubletkørsel.