Rivya AI दस्तावेज़

Rivya Task Lifecycle गाइड

Rivya task status, credit reservation, provider submission, callbacks, polling, history, notifications, failures और credits को समझें.

अंतिम समीक्षा 2026/04/28 को

Rivya में image, video या audio generation task submit करने के बाद क्या होता है, यह समझने के लिए इस guide का उपयोग करें.

यह 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 में reused होते हैं.

Submit करने पर क्या होता है

1. Rivya request validate करता है

Provider तक कुछ पहुंचने से पहले, Rivya check करता है:

  • model exists करता है
  • उस model के लिए direct generation enabled है
  • runtime async-task based है
  • prompt length valid है
  • form parameters normalized हैं
  • reference files model द्वारा accepted चीजों से match करती हैं

कुछ models में extra rules होते हैं. For example, 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 job upstream भेजने से पहले 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 होने से पहले आए, तो 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 कई जगह दिख सकता है:

  • active Studio में जब वह running हो
  • settle होने के बाद History में
  • major outcomes के लिए Notifications Center में
  • recent generations में /dashboard पर

यह shared state एक reason है कि product disposable के बजाय coherent महसूस होता है.

Chat कैसे अलग है

Chat भी billable है, लेकिन same async task record इस्तेमाल नहीं करता. 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 इस्तेमाल करते हैं
  • chat saved sessions और message-level settlement इस्तेमाल करता है

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 करें.

विषय-सूची