Forstå Rivya-genereringskøer, ventetider, langvarige bilde-, video- og lydoppgaver, varsler, historikk og trygge nye forsøk.

Bruk denne veiledningen når en bilde-, video- eller lydoppgave i Rivya blir stående under behandling lenger enn forventet.

Video, lyd, bildearbeid med mange referanser, provider-køer og større genereringsinnstillinger kan alle gjøre en oppgave tregere enn en vanlig sideinteraksjon. Venting betyr ikke i seg selv at noe har feilet.

Hva en kø betyr

En kø betyr at oppgaven ikke er ferdig ennå.

Det kan skje fordi:

provideren behandler forespørselen
arbeidsflyten tar lengre tid av design
inndataene inkluderer filer eller referanser
utdatainnstillingen er tyngre
midlertidig etterspørsel er høy
Rivya venter på en callback eller statusoppdatering

En oppgave i kø bør spores gjennom oppgavestatus, varsler og historikk, ikke sendes inn på nytt med en gang.

Venting er ikke det samme som feil

En oppgave kan være:

sendt inn
under behandling
venter på provider-resultat
fullført
mislykket

Ikke behandle alle langvarige oppgaver som mislykkede. Kontroller status før du prøver igjen.

Les Mislykkede oppgaver og tilbakeføring av credits for feilhåndtering.

Hvor du kontrollerer fremdrift

Bruk disse stedene:

arbeidsflytsiden der oppgaven ble startet
Rivya varslingssenter
Historikk i Rivya
kontoens credits og oppgavetilstand der det er tilgjengelig

Varsler hjelper fordi asynkron generering ikke bør være avhengig av én toastmelding som forsvinner.

Hva du kan gjøre mens du venter

Mens en oppgave behandles, kan du:

forberede neste promptvariant
se gjennom tidligere historikk
planlegge hvordan utdataene skal brukes
unngå å sende inn dupliserte oppgaver for raskt
bytte til en annen oppgave hvis den nåværende er asynkron

Hvis oppgaven er viktig, bør du vente på en sluttstatus før du antar at resultatet er tapt.

Når du bør prøve igjen

Prøv igjen når oppgaven tydelig har feilet, inndataene var feil, eller utdataene ikke er nyttige.

Før du prøver igjen, bør du bestemme hva som er endret:

enklere prompt
færre referanser
annen modell
annen varighet eller kvalitet
korrigert opplasting
tydeligere oppgavehensikt

Å gjenta samme forespørsel uten å endre noe kan gjenta det samme problemet.

Sjekkliste for oppgavekontinuitet

Når en oppgave må kunne spores etter innsending, bør du kontrollere:

Sjekk om oppgaven venter, kjører, er fullført, har feilet eller er klar for oppfølging.
Bruk Historikk for nyttige utdata og Varsler for asynkrone statusendringer.
Hold task UUID, modell, prompt og utdatakontekst samlet når du feilsøker.
Ikke start samme jobb på nytt før den nåværende tilstanden er klar.
Lagre eller last ned det mest nyttige resultatet før du går videre til en annen arbeidsflyt.

Målet er å unngå å miste arbeid når en generering tar tid eller trenger oppfølging.

Når du bør kontrollere status på nytt

Kontroller status på nytt når en oppgave tar lengre tid enn forventet, et varsel mangler, et resultat virker ufullstendig, eller en bruker ikke finner et tidligere resultat.

I slike tilfeller bør du undersøke oppgavetilstanden og Historikk før du ber brukeren generere på nytt.

Genereringskø og ventetider