Guide til Rivya-oppgavers livsløp

Bruk denne guiden når du trenger å forstå hva som skjer etter at du sender inn en bilde-, video- eller lydgenereringsoppgave i Rivya.

Den forklarer oppgavestatus, credit-reservasjon, provider-fullføring, historikk, varsler og håndtering av feilede oppgaver samlet på ett sted.

De faktiske oppgavestatusene

Dagens asynkrone genereringslivsløp bruker fire synlige statuser:

• WAITING
• GENERATING
• SUCCESS
• FAILED

Disse statusene lagres på ai_task og gjenbrukes på tvers av Studio, historikk, dashboard og varslingsflyt.

Hva som skjer når du sender inn

1. Rivya validerer forespørselen

Før noe når en provider, sjekker Rivya:

• at modellen finnes
• at direkte generering er aktivert for den modellen
• at runtime er basert på asynkrone oppgaver
• at promptlengden er gyldig
• at skjemaparametere er normalisert
• at referansefiler passer med det modellen godtar

Noen modeller har ekstra regler. For eksempel krever lydisolering en opplastet lydfil pluss varighetskontroll.

2. Rivya oppretter oppgaveposten

Rivya oppretter først en ai_task-oppføring med status WAITING.

Denne oppføringen lagrer modell, kategori, prompt, parametere, reserverte credits, faktureringstype og senere resultatet eller feiltilstanden.

3. Credits forbrukes før provider-innsending

Dette er viktig: For asynkron generering bruker Rivya oppgavens credits før jobben sendes oppstrøms.

Hvis det er for få credits:

• oppgaven merkes som feilet
• oppstrømstjenesten blir aldri kalt
• et varsel om utilstrekkelige credits kan opprettes

4. Provider-jobben opprettes

Hvis credits er tilgjengelige, sender Rivya oppgaven til den matchende oppstrømstjenesten og lagrer oppstrøms oppgave-ID.

Da går statusen til GENERATING.

Hvordan Rivya får vite resultatet

Rivya støtter to fullføringsveier:

• provider-callback i miljøer der callbacks er aktivert
• statusoppdatering og polling når callback-fullføring ikke er tilgjengelig

Callback-veien verifiserer også webhook-signaturen før en oppgave ferdigstilles.

Hvis en callback kommer før provider-resultatet er helt klart, kan Rivya utsette behandlingen og prøve igjen ved å sjekke oppstrømsstatus.

Vellykket løp

Ved suksess gjør Rivya dette:

• lagrer resultat-URL-er
• setter status til SUCCESS
• avregner oppgaven
• gjør resultatet tilgjengelig i genereringshistorikken
• oppretter et varsel om vellykket generering

Derfor forblir et ferdig bilde eller en ferdig video synlig etter at du forlater siden.

Feilløp

Ved feil gjør Rivya dette:

• lagrer feilmeldingen
• setter status til FAILED
• refunderer credits når feilen skjedde etter reservasjon og bør reverseres
• oppretter et varsel om feilet generering for varig gjennomgang

Dette er annerledes enn en midlertidig toast. Feilen blir en del av kontoens logg.

Hvor du ser oppgavestatus

Den samme oppgaven kan vises flere steder:

• i aktivt Studio mens den kjører
• i History etter at den er avsluttet
• i Notifications Center for viktige utfall
• på /dashboard i nylige genereringer

Denne delte statusen er en av grunnene til at produktet føles sammenhengende i stedet for midlertidig.

Hvordan Chat skiller seg ut

Chat er også fakturerbar, men bruker ikke samme asynkrone oppgavepost. Chat-runder lagres som:

• chatøkter
• chatmeldinger

For token-baserte chatmodeller kan Rivya reservere credits først og deretter avregne sluttbeløpet når bruken kommer tilbake. Hvis sluttbeløpet er lavere, refunderes differansen.

Den brede regelen er derfor:

• bilde-, video- og lydgenerering bruker ai_task
• chat bruker lagrede økter og avregning på meldingsnivå

Les videre

• Image-arbeidsflyter i Rivya
• Video-arbeidsflyter i Rivya
• Audio-arbeidsflyter i Rivya
• Credits og fakturering
• Feilsøking i Rivya
• Notifications Center
• History

Sjekkliste for oppgavestatus

Når en generering er forvirrende, treg, feilet eller mangler, bør du sjekke:

• Identifiser oppgavetypen først: chat-avregning, bilde, video, lyd eller verktøystøttet chat.
• Sjekk om credits ble reservert før provider-innsending eller avregnet etter bruk.
• Se etter provider-callback, pollingresultat, historikkpost og varsel før du antar at resultatet er tapt.
• Skill brukerrettbare feil fra provider- eller infrastrukturfeil.
• Bekreft om en feilet oppgave bør reversere credits før du kjører samme prompt på nytt.

Sjekk på nytt før du kjører igjen

Sjekk på nytt når samme prompt fortsetter å feile, en oppgave står for lenge i prosess, credits ser ut til å være brukt uten resultat, eller du er i ferd med å sende inn en tyngre duplikatkjøring.