Nieodwracalność zadań i ponawianie

Po zaakceptowaniu createTask zadanie generowania jest wiążące i nie można go anulować. Dotyczy to zarówno stanu queued, jak i running: po rozpoczęciu generowania nie da się niezawodnie go zatrzymać. Dlatego SpicyAPI nie udostępnia lokalnej operacji, która mogłaby zgłosić anulowanie, choć praca — i jej koszt — nadal trwałyby.

Ponów zadanie w stanie końcowym

Ponowienie uruchamia jeszcze raz zakończone zadanie, które się nie powiodło: tworzy nowe zadanie z tym samym modelem, input i adresem callback, więc nie musisz ponownie wysyłać treści pierwotnego żądania. Nowe zadanie jest rozliczane jak każde inne: szacowana opłata zostaje zablokowana przy akceptacji, a opłata jest pobierana tylko wtedy, gdy zadanie zakończy się powodzeniem.

POST /api/v1/jobs/retry

curl -X POST https://api.spicyapi.ai/api/v1/jobs/retry \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: retry-order-8814-1" \
  -d '{"taskId":"job_01k3m8x9q2z4v7n5p6r8s0t1w3"}'

Zastąp przykładowe taskId identyfikatorem zadania zakończonego błędem. Zawsze wysyłaj nagłówek Idempotency-Key przy retry (na przykład retry-<sourceTaskId>-1): bez niego podwójne kliknięcie lub ponowienie żądania po błędzie sieci utworzy dwa płatne zadania.

Ponawiać należy tylko zadania failed i expired. Historyczne rekordy canceled pozostają dostępne do odczytu i również można je ponowić dla zachowania zgodności wstecznej, ale nowe zadania nie mogą przejść do tego stanu w wyniku działania użytkownika. Powodzenie tej operacji tworzy nowe zadanie w kolejce i zwraca HTTP 200 (a nie 202, jak createTask), z code: 200:

{
  "code": 200,
  "msg": "success",
  "data": {
    "taskId": "job_01k3mnewtask",
    "sourceTaskId": "job_01k3m8x9q2z4v7n5p6r8s0t1w3",
    "state": "queued",
    "estimatedCost": "0.08",
    "deadlineAt": "2026-08-28T10:12:04Z"
  },
  "request_id": "req_01k3mretry"
}

Sprawdzaj stan lub czekaj na nowe taskId, nie na identyfikator zadania źródłowego; zobacz Zadania asynchroniczne.

• Zadanie źródłowe pozostaje w stanie końcowym i nie zmienia się.
• sourceTaskId nowego zadania wskazuje zadanie źródłowe, zachowując historię ponowień.
• Ponownie sprawdzane są aktualny schemat, cena, uprawnienia i saldo. Ponowienie to nowe zadanie: trafia ponownie do kolejki i jest przetwarzane niezależnie od zadania źródłowego.
• Nowe zadanie wysyła callback na ten sam callBackUrl co zadanie źródłowe i zachowuje jego okres przechowywania; nagłówek X-Spicy-Retention przesłany do retry jest ignorowany.
• Ponowienie używa dokładnie tego samego input co zadanie źródłowe. Pliki referencyjne przesłane do SpicyAPI — w tym małe obrazy Base64, które są zapisywane jako przesłane pliki — są dostępne przez jeden dzień. Później ponowienie zwraca 400: prześlij plik jeszcze raz i utwórz nowe zadanie przez createTask.
• Zakres Idempotency-Key obejmuje zadanie źródłowe i operację ponowienia. Użycie tego samego klucza dla tego samego zadania źródłowego zwraca to samo nowe zadanie zamiast tworzyć kolejne.

Kiedy ponowienie jest odrzucane

Gdy retry zwraca błąd, żadne środki nie są blokowane ani pobierane.

Stany zadań i dostępne działania

Przed ponowieniem sprawdź errorCode. Przy rate_limited, upstream_unavailable i upstream_failed warto spróbować ponownie; timeout i generation_failed mogą znów zakończyć się tak samo. W przypadku invalid_request, unsupported_combination i content_rejected te same dane wejściowe ponownie spowodują błąd, a przy invalid_asset trzeba jeszcze raz przesłać plik referencyjny — zmień dane wejściowe i zamiast ponowienia użyj createTask. Zobacz Kody niepowodzenia zadań.