Rivya task status، credit reservation، provider submission، callbacks، polling، history، notifications، failures، اور credits سمجھیں۔

یہ guide اس وقت استعمال کریں جب آپ کو سمجھنا ہو کہ Rivya میں image، video، یا audio generation task submit کرنے کے بعد کیا ہوتا ہے۔

یہ task states، credit reservation، provider completion، history، notifications، اور failed-task handling کو ایک جگہ explain کرتا ہے۔

Real task states

Current async generation lifecycle چار visible states استعمال کرتا ہے:

WAITING
GENERATING
SUCCESS
FAILED

یہ states ai_task پر stored ہیں اور Studio، history، dashboard، اور notifications flow میں reuse ہوتے ہیں۔

Submit کرنے پر کیا ہوتا ہے

1. Rivya request validate کرتا ہے

Provider تک کچھ پہنچنے سے پہلے Rivya check کرتا ہے:

model exists
direct generation اس model کے لیے enabled ہے
runtime async-task based ہے
prompt length valid ہے
form parameters normalized ہیں
reference files model کے accepted inputs سے match کرتی ہیں

کچھ models کے extra rules ہوتے ہیں۔ مثال کے طور پر audio isolation کو uploaded audio file plus duration verification چاہیے۔

2. Rivya task record create کرتا ہے

Rivya پہلے ai_task entry create کرتا ہے، status WAITING کے ساتھ۔

یہ record model، category، prompt، params، reserved credits، billing type، اور بعد میں result یا failure state store کرتا ہے۔

3. Provider submission سے پہلے credits consume ہوتے ہیں

یہ important ہے: async generation کے لیے Rivya upstream job بھیجنے سے پہلے task credits spend کرتا ہے۔

اگر credits too low ہوں:

task failed marked ہوتا ہے
upstream service کبھی call نہیں ہوتی
insufficient-credit notification create ہو سکتی ہے

4. Provider job create ہوتی ہے

اگر credits available ہوں، تو Rivya task کو matching upstream service پر submit کرتا ہے اور upstream task ID store کرتا ہے۔

اس point پر status GENERATING میں move ہوتا ہے۔

Rivya result کیسے جانتا ہے

Rivya دو completion paths support کرتا ہے:

callback-enabled environments میں provider callback
جب callback completion available نہ ہو تو status refresh اور polling

Callback path task finalize کرنے سے پہلے webhook signature بھی verify کرتا ہے۔

اگر callback provider result fully ready ہونے سے پہلے arrive ہو، تو Rivya defer کر سکتا ہے اور upstream status check کر کے دوبارہ try کر سکتا ہے۔

Success path

Success پر Rivya:

result URLs store کرتا ہے
status SUCCESS set کرتا ہے
task settle کرتا ہے
output کو generation history میں available بناتا ہے
generation-success notification create کرتا ہے

اسی لیے finished image یا video page چھوڑنے کے بعد بھی visible رہتی ہے۔

Failure path

Failure پر Rivya:

error message store کرتا ہے
status FAILED set کرتا ہے
جب failure reservation کے بعد ہوا ہو اور reverse ہونا چاہیے ہو تو credits refund کرتا ہے
durable review کے لیے generation-failed notification create کرتا ہے

یہ temporary toast سے مختلف ہے۔ Failure account کے record کا حصہ بن جاتا ہے۔

Task state کہاں دکھتی ہے

Same task کئی جگہوں پر show ہو سکتی ہے:

active Studio میں جب یہ running ہو
settle ہونے کے بعد History
major outcomes کے لیے Notifications Center
recent generations میں /dashboard

یہ shared state ان وجوہات میں سے ایک ہے کہ product disposable کے بجائے coherent محسوس ہوتا ہے۔

Chat کیسے different ہے

Chat بھی billable ہے، مگر وہ same async task record use نہیں کرتا۔ Chat turns اس طرح stored ہوتے ہیں:

chat sessions
chat messages

Token-based chat models کے لیے Rivya پہلے credits reserve کر سکتا ہے اور پھر usage واپس آنے کے بعد final amount settle کر سکتا ہے۔ اگر final amount lower ہو تو difference refunded ہوتا ہے۔

Broad rule یہ ہے:

image، video، اور audio generation ai_task use کرتے ہیں
chat saved sessions اور message-level settlement use کرتا ہے

آگے پڑھیں

Task state checklist

جب generation confusing، slow، failed، یا missing ہو، تو check کریں:

پہلے task type identify کریں: chat settlement، image، video، audio، یا tool-backed chat۔
Check کریں کہ credits provider submission سے پہلے reserved ہوئے یا usage کے بعد settled ہوئے۔
Result lost assume کرنے سے پہلے provider callback، polling result، history item، اور notification دیکھیں۔
User-correctable failures کو provider یا infrastructure failures سے الگ کریں۔
Same prompt rerun کرنے سے پہلے confirm کریں کہ failed task کو credits reverse کرنے چاہئیں یا نہیں۔

دوبارہ run کرنے سے پہلے recheck کریں

جب same prompt بار بار fail ہو، task بہت دیر تک in progress رہے، credits output کے بغیر consumed لگیں، یا آپ heavier duplicate run submit کرنے والے ہوں، تو recheck کریں۔

Rivya task lifecycle گائیڈ