Rivya generation queues، waiting times، long-running image، video، audio tasks، notifications، history، اور safe retries سمجھیں۔

جب Rivya image، video، یا audio task expected سے زیادہ دیر in progress رہے تو یہ guide استعمال کریں۔

Video، audio، reference-heavy image work، provider queues، اور larger generation settings سب task کو normal page interaction سے slow بنا سکتے ہیں۔ Waiting by itself failure نہیں ہے۔

Queue کا کیا مطلب ہے

Queue کا مطلب ہے task ابھی finish نہیں ہوا۔

یہ اس وجہ سے ہو سکتا ہے:

provider request process کر رہا ہے
workflow design کے لحاظ سے longer لیتا ہے
input میں files یا references شامل ہیں
output setting heavier ہے
temporary demand high ہے
Rivya callback یا status update کا انتظار کر رہا ہے

Queued task کو فوراً repeat کرنے کے بجائے task status، notifications، اور history کے ذریعے track کرنا چاہیے۔

Waiting failure جیسا نہیں ہے

Task ہو سکتا ہے:

submitted
processing
provider result کا waiting
completed
failed

ہر long-running task کو failed نہ سمجھیں۔ Retry کرنے سے پہلے status check کریں۔

Failure behavior کے لیے Failed tasks اور credit refunds پڑھیں۔

Progress کہاں check کریں

یہ places استعمال کریں:

وہ workflow page جہاں task start ہوا
Rivya Notifications Center
Rivya میں history
available ہو تو account credit اور task state

Notifications help کرتے ہیں کیونکہ async generation کو ایک disappearing toast پر depend نہیں کرنا چاہیے۔

Waiting کے دوران کیا کریں

Task processing میں ہو تو آپ:

next prompt variation prepare کر سکتے ہیں
previous history review کر سکتے ہیں
output کیسے use ہوگا plan کر سکتے ہیں
duplicate tasks بہت quickly submit کرنے سے بچ سکتے ہیں
اگر current task asynchronous ہے تو another task پر switch کر سکتے ہیں

اگر task important ہے تو result lost assume کرنے سے پہلے final status کا انتظار کریں۔

Retry کب کریں

Retry اس وقت کریں جب task clearly failed ہو، input wrong ہو، یا output useful نہ ہو۔

Retry سے پہلے decide کریں کہ کیا change ہوا:

simpler prompt
fewer references
different model
different duration یا quality
corrected upload
clearer task intent

کچھ change کیے بغیر same request repeat کرنے سے same problem repeat ہو سکتی ہے۔

Task continuity checklist

جب task کو submission کے بعد traceable رہنا ہو تو check کریں:

Check کریں کہ task pending، running، completed، failed، یا follow-up کے لیے ready ہے۔
Useful outputs کے لیے History اور async status changes کے لیے Notifications استعمال کریں۔
Troubleshooting کے وقت task UUID، model، prompt، اور output context ساتھ رکھیں۔
جب تک current state clear نہ ہو same job restart نہ کریں۔
Another workflow میں branch کرنے سے پہلے most useful result save یا download کریں۔

Goal یہ ہے کہ generation time لے یا follow-up چاہیے ہو تو work lost نہ ہو۔

Status کب recheck کریں

Status recheck کریں جب task expected سے زیادہ time لے، notification missing ہو، result incomplete لگے، یا user previous output نہ ڈھونڈ سکے۔

ان cases میں user کو regenerate کہنے سے پہلے task state اور History inspect کریں۔

Generation queue اور waiting times