Lees hoe Rivya-wachtrijen en wachttijden werken bij langdurige beeld-, video- en audiotaken, inclusief meldingen, geschiedenis en veilige nieuwe pogingen.

Gebruik deze gids wanneer een beeld-, video- of audiotaak in Rivya langer dan verwacht wordt verwerkt.

Video, audio, reference-heavy imagewerk, providerqueues en zwaardere generatie-instellingen kunnen een taak allemaal trager maken dan een normale page interaction. Wachten betekent op zichzelf geen failure.

Wat een queue betekent

Een queue betekent dat de taak nog niet klaar is.

Dat kan gebeuren omdat:

de provider de request verwerkt
de workflow bewust langer duurt
de input files of references bevat
de outputsetting zwaarder is
tijdelijke demand hoog is
Rivya wacht op een callback of statusupdate

Een queued task moet worden gevolgd via task status, notifications en history in plaats van meteen herhaald.

Wachten is niet hetzelfde als falen

Een taak kan zijn:

submitted
processing
wachten op providerresultaat
completed
failed

Behandel niet elke langlopende taak als failed. Controleer de status voordat je retryt.

Lees Mislukte taken en creditrefunds voor failure behavior.

Waar je voortgang controleert

Gebruik deze plekken:

de workflowpagina waar de taak startte
Rivya Meldingencentrum
Geschiedenis in Rivya
accountcredits en task state waar beschikbaar

Notifications helpen omdat async generation niet afhankelijk moet zijn van een enkele toast die verdwijnt.

Wat je doet terwijl je wacht

Terwijl een taak processing is, kun je:

de volgende promptvariant voorbereiden
eerdere history reviewen
plannen hoe de output wordt gebruikt
te snel duplicate tasks indienen vermijden
naar een andere taak wisselen als de huidige async is

Als de taak belangrijk is, wacht dan op een finale status voordat je aanneemt dat het resultaat verloren is.

Wanneer je retryt

Retry wanneer de taak duidelijk failed is, de input fout was of de output niet bruikbaar is.

Bepaal voor retry wat er veranderde:

eenvoudigere prompt
minder references
ander model
andere duration of quality
gecorrigeerde upload
duidelijkere task intent

Dezelfde request herhalen zonder iets te veranderen kan hetzelfde probleem herhalen.

Checklist voor taakcontinuïteit

Wanneer een taak na submission traceable moet blijven, controleer je:

Controleer of de taak pending, running, completed, failed of ready for follow-up is.
Gebruik History voor nuttige outputs en Notifications voor async status changes.
Houd task UUID, model, prompt en outputcontext bij elkaar tijdens troubleshooting.
Start dezelfde job niet opnieuw totdat de huidige state duidelijk is.
Bewaar of download het nuttigste resultaat voordat je naar een andere workflow vertakt.

Het doel is werk niet kwijt te raken wanneer een generation tijd kost of follow-up nodig heeft.

Wanneer je status opnieuw controleert

Controleer status opnieuw wanneer een taak langer duurt dan verwacht, een notification ontbreekt, een resultaat incompleet lijkt of een gebruiker een eerdere output niet kan vinden.

Inspecteer in die gevallen task state en History voordat je de gebruiker vraagt opnieuw te genereren.

Generatiewachtrij en wachttijden