了解 Rivya task status、credit reservation、provider submission、callbacks、polling、history、notifications、failures 和 credits。

當你需要了解在 Rivya 提交 image、video 或 audio generation task 之後會發生什麼，請使用這份指南。

它會把 task states、credit reservation、provider completion、history、notifications 和 failed-task handling 放在同一處說明。

真實 Task States

目前 async generation lifecycle 使用四個可見狀態：

WAITING
GENERATING
SUCCESS
FAILED

這些狀態儲存在 ai_task 上，並會在 Studio、history、dashboard 和 notifications flow 中重複使用。

提交後會發生什麼

1. Rivya 驗證 request

在任何內容送到 provider 前，Rivya 會檢查：

model 是否存在
該 model 是否啟用 direct generation
runtime 是否是 async-task based
prompt length 是否有效
form parameters 是否已 normalized
reference files 是否符合 model 接受的內容

有些 models 有額外規則。例如，audio isolation 需要 uploaded audio file 以及 duration verification。

2. Rivya 建立 task record

Rivya 會先建立一筆 ai_task entry，狀態為 WAITING。

該 record 會儲存 model、category、prompt、params、reserved credits、billing type，以及之後的 result 或 failure state。

3. Credits 會在 provider submission 前消耗

這點很重要：對 async generation 而言，Rivya 會在把 job 送往上游前，先花費該 task 的 credits。

如果 credits 太低：

task 會被標記為 failed
upstream service 不會被呼叫
可以建立 insufficient-credit notification

4. Provider job 被建立

如果 credits 可用，Rivya 會將 task 提交到對應的 upstream service，並儲存 upstream task ID。

這時 status 會移到 GENERATING。

Rivya 如何知道結果

Rivya 支援兩種完成路徑：

在 callback-enabled environments 中使用 provider callback
callback completion 不可用時，使用 status refresh 和 polling

Callback path 在 finalize task 前，也會驗證 webhook signature。

如果 callback 抵達時 provider result 還沒有完全 ready，Rivya 可以 defer，並透過檢查 upstream status 再試一次。

Success Path

成功時，Rivya 會：

儲存 result URLs
將 status 設為 SUCCESS
settle task
讓 output 出現在 generation history
建立 generation-success notification

這就是為什麼完成的 image 或 video 在你離開頁面後仍然可見。

Failure Path

失敗時，Rivya 會：

儲存 error message
將 status 設為 FAILED
當 failure 發生在 reservation 之後且應該 reversal 時 refund credits
建立 generation-failed notification，供 durable review

這和暫時 toast 不同。failure 會成為 account record 的一部分。

在哪裡看到 Task State

同一個 task 可能出現在多個地方：

正在執行時的 active Studio
settled 後的 History
重大結果的 Notifications Center
/dashboard 中的 recent generations

這種 shared state 是產品感覺連貫、而不是一次性工具的原因之一。

Chat 有什麼不同

Chat 也會 billable，但它不使用同一個 async task record。Chat turns 會儲存為：

chat sessions
chat messages

對 token-based chat models 而言，Rivya 可以先 reserve credits，再在 usage 回來後 settle final amount。如果 final amount 較低，差額會 refund。

所以大致規則是：

image、video 和 audio generation 使用 ai_task
chat 使用 saved sessions 和 message-level settlement

接著閱讀

Task State Checklist

當 generation 令人困惑、變慢、失敗或遺失時，請檢查：

先識別 task type：chat settlement、image、video、audio，或 tool-backed chat。
檢查 credits 是在 provider submission 前 reserved，還是在 usage 後 settled。
在假設 result 遺失前，先找 provider callback、polling result、history item 和 notification。
分離 user-correctable failures 與 provider 或 infrastructure failures。
重新執行同一個 prompt 前，確認 failed task 是否應該 reverse credits。

再次執行前重新檢查

當同一個 prompt 持續失敗、task in progress 太久、credits 看起來已消耗但沒有 output，或你準備提交更重的 duplicate run 時，請重新檢查。

Rivya Task Lifecycle 指南