Przewodnik po cyklu życia zadań w Rivya

Użyj tego przewodnika, gdy chcesz zrozumieć, co dzieje się po przesłaniu zadania generowania obrazu, wideo albo audio w Rivya.

Wyjaśnia w jednym miejscu stany zadań, rezerwację credits, ukończenie po stronie providera, historię, powiadomienia i obsługę nieudanych zadań.

Rzeczywiste Stany Zadania

Obecny async lifecycle generowania używa czterech widocznych stanów:

• WAITING
• GENERATING
• SUCCESS
• FAILED

Te stany są zapisywane na ai_task i ponownie używane w przepływie Studio, historii, dashboardu i powiadomień.

Co Się Dzieje Po Przesłaniu

1. Rivya waliduje żądanie

Zanim cokolwiek trafi do providera, Rivya sprawdza:

• czy model istnieje
• czy bezpośrednie generowanie jest włączone dla tego modelu
• czy runtime jest oparty na async-task
• czy długość promptu jest poprawna
• czy parametry formularza są znormalizowane
• czy pliki referencyjne pasują do tego, co akceptuje model

Niektóre modele mają dodatkowe reguły. Na przykład izolacja audio wymaga uploadowanego pliku audio oraz weryfikacji czasu trwania.

2. Rivya tworzy rekord zadania

Rivya najpierw tworzy wpis ai_task ze statusem WAITING.

Ten rekord przechowuje model, kategorię, prompt, params, zarezerwowane credits, typ rozliczenia, a później wynik albo stan błędu.

3. Credits są zużywane przed wysyłką do providera

To ważne: dla generowania async Rivya wydaje credits zadania przed wysłaniem pracy upstream.

Jeśli credits są za niskie:

• zadanie jest oznaczane jako nieudane
• usługa upstream nigdy nie jest wywoływana
• może zostać utworzone powiadomienie o niewystarczającej liczbie credits

4. Tworzone jest zadanie providera

Jeśli credits są dostępne, Rivya przesyła zadanie do pasującej usługi upstream i zapisuje upstream task ID.

W tym momencie status przechodzi na GENERATING.

Jak Rivya Poznaje Wynik

Rivya obsługuje dwie ścieżki ukończenia:

• callback providera w środowiskach z włączonym callback
• odświeżanie statusu i polling, gdy ukończenie przez callback nie jest dostępne

Ścieżka callback weryfikuje też podpis webhooka przed finalizacją zadania.

Jeśli callback przychodzi, zanim wynik providera jest w pełni gotowy, Rivya może odroczyć i spróbować ponownie, sprawdzając status upstream.

Ścieżka Sukcesu

Po sukcesie Rivya:

• zapisuje URL-e wyników
• ustawia status na SUCCESS
• rozlicza zadanie
• udostępnia wynik w historii generowania
• tworzy powiadomienie o sukcesie generowania

Dlatego ukończony obraz albo wideo pozostaje widoczne po opuszczeniu strony.

Ścieżka Błędu

Po błędzie Rivya:

• zapisuje komunikat błędu
• ustawia status na FAILED
• zwraca credits, gdy błąd nastąpił po rezerwacji i powinien zostać odwrócony
• tworzy powiadomienie o nieudanym generowaniu do trwałego przeglądu

To różni się od tymczasowego toasta. Błąd staje się częścią rekordu konta.

Gdzie Widzisz Stan Zadania

To samo zadanie może pojawić się w kilku miejscach:

• w aktywnym Studio, gdy nadal działa
• w Przewodnik po historii Rivya po rozliczeniu
• w Przewodnik po Rivya Notifications Center dla ważnych wyników
• w /dashboard w ostatnich generowaniach

Ten wspólny stan jest jednym z powodów, dla których produkt wydaje się spójny, a nie jednorazowy.

Czym Różni Się Chat

Chat też jest rozliczany, ale nie używa tego samego rekordu async task. Tury chatu są zapisywane jako:

• sesje chatu
• wiadomości chatu

Dla modeli chatu opartych na tokenach Rivya może najpierw zarezerwować credits, a potem rozliczyć finalną kwotę po powrocie użycia. Jeśli finalna kwota jest niższa, różnica jest zwracana.

Szeroka reguła brzmi więc:

• generowanie obrazu, wideo i audio używa ai_task
• chat używa zapisanych sesji i rozliczenia na poziomie wiadomości

Czytaj Dalej

• Workflow obrazów w Rivya
• Workflow wideo w Rivya
• Workflow audio w Rivya
• Credits i rozliczenia
• Rozwiązywanie problemów w Rivya
• Przewodnik po Rivya Notifications Center

Checklista Stanu Zadania

Gdy generowanie jest mylące, wolne, nieudane albo brakujące, sprawdź:

• Najpierw zidentyfikuj typ zadania: rozliczenie chatu, obraz, wideo, audio albo chat wspierany narzędziem.
• Sprawdź, czy credits zostały zarezerwowane przed wysyłką do providera czy rozliczone po użyciu.
• Poszukaj callbacku providera, wyniku pollingu, elementu historii i powiadomienia, zanim uznasz wynik za utracony.
• Oddziel błędy możliwe do poprawienia przez użytkownika od błędów providera albo infrastruktury.
• Potwierdź, czy nieudane zadanie powinno odwrócić credits przed ponownym uruchomieniem tego samego promptu.

Sprawdź Ponownie Przed Kolejnym Uruchomieniem

Sprawdź ponownie, gdy ten sam prompt wciąż zawodzi, zadanie zbyt długo pozostaje w toku, credits wyglądają na zużyte bez wyniku albo masz zamiar przesłać cięższe zduplikowane uruchomienie.