Rivya Task Lifecycle Guide

Use this guide when you need to understand what happens after submitting an image, video, or audio generation task in Rivya.

It explains task states, credit reservation, provider completion, history, notifications, and failed-task handling in one place.

The Real Task States

The current async generation lifecycle uses four visible states:

• WAITING
• GENERATING
• SUCCESS
• FAILED

Those states are stored on ai_task and reused across the Studio, history, dashboard, and notifications flow.

What Happens When You Submit

1. Rivya validates the request

Before anything reaches a provider, Rivya checks:

• the model exists
• direct generation is enabled for that model
• the runtime is async-task based
• prompt length is valid
• form parameters are normalized
• reference files match what the model accepts

Some models have extra rules. For example, audio isolation requires an uploaded audio file plus duration verification.

2. Rivya creates the task record

Rivya creates an ai_task entry first, with status WAITING.

That record stores the model, category, prompt, params, reserved credits, billing type, and later the result or failure state.

3. Credits are consumed before provider submission

This is important: for async generation, Rivya spends the task credits before sending the job upstream.

If credits are too low:

• the task is marked failed
• the upstream service is never called
• an insufficient-credit notification can be created

4. The provider job is created

If credits are available, Rivya submits the task to the matching upstream service and stores the upstream task ID.

At that point the status moves to GENERATING.

How Rivya Learns the Result

Rivya supports two completion paths:

• provider callback in callback-enabled environments
• status refresh and polling when callback completion is not available

The callback path also verifies the webhook signature before finalizing a task.

If a callback arrives before the provider result is fully ready, Rivya can defer and try again by checking upstream status.

Success Path

On success, Rivya:

• stores result URLs
• sets status to SUCCESS
• settles the task
• makes the output available in generation history
• creates a generation-success notification

That is why a finished image or video stays visible after you leave the page.

Failure Path

On failure, Rivya:

• stores the error message
• sets status to FAILED
• refunds credits when the failure happened after reservation and should be reversed
• creates a generation-failed notification for durable review

This is different from a temporary toast. The failure becomes part of the account’s record.

Where You See Task State

The same task can show up in several places:

• the active Studio while it is running
• History after it settles
• Notifications Center for major outcomes
• /dashboard in recent generations

That shared state is one of the reasons the product feels coherent instead of disposable.

How Chat Differs

Chat is also billable, but it does not use the same async task record. Chat turns are stored as:

• chat sessions
• chat messages

For token-based chat models, Rivya can reserve credits first and then settle the final amount after usage comes back. If the final amount is lower, the difference is refunded.

So the broad rule is:

• image, video, and audio generation use ai_task
• chat uses saved sessions and message-level settlement

Read Next

• Image Workflows in Rivya
• Video Workflows in Rivya
• Audio Workflows in Rivya
• Credits & Billing
• Troubleshooting in Rivya
• Notifications Center
• History

Task State Checklist

When a generation is confusing, slow, failed, or missing, check:

• Identify the task type first: chat settlement, image, video, audio, or tool-backed chat.
• Check whether credits were reserved before provider submission or settled after usage.
• Look for the provider callback, polling result, history item, and notification before assuming the result is lost.
• Separate user-correctable failures from provider or infrastructure failures.
• Confirm whether a failed task should reverse credits before rerunning the same prompt.

Recheck Before Running Again

Recheck when the same prompt keeps failing, a task stays in progress too long, credits look consumed without output, or you are about to submit a heavier duplicate run.