# Jak uniknąć podwójnych zadań wideo po timeoutcie żądania API? > Zapobiegaj duplikatom przez stabilny klucz operacji dla każdego zamierzonego wyniku, zapis żądania przed wysłaniem, dokumentowaną idempotencję dostawcy i uzgadnianie niejednoznacznych timeoutów przed retry. Timeout oznacza wynik nieznany, nie odrzucenie. # Jak uniknąć podwójnych zadań wideo po timeoutcie żądania API? Timeout wysyłania tworzy niejednoznaczny wynik. Żądanie mogło zawieść przed dotarciem, zostać odrzucone albo utworzyć zdalne zadanie, którego odpowiedź nie wróciła. Natychmiastowy retry może zmienić jeden klip w dwie płatne generacje. Rozwiązaniem jest idempotentna warstwa operacji wokół API. Najpierw utwórz i zapisz zamierzoną operację, nadaj jej stabilny klucz, rejestruj każdą próbę i używaj dokumentowanej idempotencji lub wyszukiwania. Jeśli wyniku zdalnego nie można udowodnić, ustaw jawny stan nieznany. ## Zdefiniuj jeden zamierzony skutek Klucz musi identyfikować to, co użytkownik chce utworzyć, a nie pojedynczą próbę HTTP. Jeśli każdy retry ma nowy klucz, dostawca nie rozpozna duplikatu. Operację katalogową mogą określać: * ID produktu; * wersja szablonu; * odcisk mediów źródłowych; * wersja promptu; * język; * proporcja; * nazwa wariantu. Zbuduj kanoniczną reprezentację ze stałą kolejnością i znormalizowanymi wartościami, potem hash. Przechowuj czytelne wymiary obok. Celowo nowa generacja powinna mieć nową operację lub wariant, nawet przy tym samym promptcie. Nie generuj losowego UUID w pętli retry. Utwórz klucz przed pierwszym żądaniem i używaj aż do stanu końcowego. ## Zapisuj przed wysłaniem Lokalna baza musi znać operację przed wywołaniem sieci. To zasada write-ahead dla skutków API. | Pole | Cel | |---|---| | Klucz operacji | Zapobiega podwójnej lokalnej intencji | | Hash żądania | Dowodzi wysłanych parametrów | | Stan | Rozróżnia przygotowane, wysłane, nieznane i ukończone | | Liczba prób | Stosuje ograniczoną politykę | | Dostawca i model | Wspiera routing i uzgodnienie | | Zdalny ID | Wznawia polling bez ponownego wysłania | | Ostatni błąd | Zachowuje kontekst diagnozy | | Checksum wyniku | Wykrywa duplikaty lub zmiany | Ustaw unikalność klucza. Dwaj workerzy tworzący tę samą operację mają zbiec się w jednym rekordzie. Przejmij go atomowo lub dzierżawą przed wysłaniem. ## Używaj idempotencji tylko zgodnie z dokumentacją Niektóre API przyjmują klucz i przy powtórzeniu zwracają pierwszy zaakceptowany wynik. To najlepsza ścieżka, jeśli dokumentacja opisuje endpoint, okres przechowywania, porównanie parametrów i błędy. Sprawdź: * czy endpoint wideo obsługuje klucz; * jak długo jest pamiętany; * czy ten sam klucz z innymi parametrami jest odrzucany; * czy retry zwraca pierwotny zdalny ID. Nie zakładaj, że nagłówek do płatności lub tekstu działa dla asynchronicznego wideo. Format zgodny z OpenAI nie czyni tworzenia zadań automatycznie idempotentnym. ## Traktuj timeout jako wynik nieznany | Stan | Dowód | Następne działanie | |---|---|---| | `prepared` | Rekord istnieje, wysyłanie nie zaczęte | Wyślij | | `sending` | Worker rozpoczął żądanie | Czekaj na wynik lub timeout | | `accepted` | Otrzymano zdalny ID | Odpytuj | | `unknown` | Timeout bez potwierdzenia | Uzgodnij | | `failed` | Jawne odrzucenie lub błąd końcowy | Zastosuj politykę | | `complete` | Wynik zapisany trwale | Zwróć istniejący wynik | Różnica między `unknown` i `failed` jest kluczowa. Wyjątek sieci mówi o połączeniu klienta, niekoniecznie o pracy dostawcy. Jeśli API pozwala na metadane lub referencję klienta, dołącz lokalny klucz, aby później wyszukać stabilną wartość. ## Uzgadniaj przed retry Worker uzgodnienia bada nieznaną operację: 1. Sprawdza, czy przed awarią zapisano zdalny ID. 2. Odpytuje po kluczu lub referencji, jeśli obsługiwane. 3. Szuka w ograniczonej liście po czasie, modelu i odcisku. 4. Sprawdza webhooks przybyłe po timeoutcie. 5. Porównuje zdarzenia użycia lub faktury, jeśli są dostępne. 6. Ponawia tylko przy dowodzie braku zadania lub bezpiecznej idempotencji. Czas i prompt mogą dawać fałszywe trafienia. Używaj wielu cech i kieruj niepewne wyniki do review. Bez lookupu lub gwarancji polityka może wymagać oczekiwania, akceptacji ryzyka lub decyzji człowieka. ## Oddziel retry transportowe od generacyjnych Biblioteki HTTP mogą automatycznie ponawiać błędy sieci. To pomaga w odczytach, ale zagraża wysłaniom ze skutkami. Wyłącz ogólne retry POST, jeśli operacja nie ma stabilnego klucza i dokumentowanego zachowania. Używaj dwóch liczników: * prób transportowych tej samej chronionej operacji; * prób generacyjnych tworzących zamiennik po błędzie końcowym lub odrzuceniu jakości. Retry transportowy ma zbiec się w tym samym zadaniu. Retry generacyjny jest nową płatną próbą kreatywną z własną tożsamością, połączoną z pierwotnym zadaniem. ## Obsługuj współbieżnych workerów dzierżawą Timeout nie jest jedynym źródłem duplikatów. Dwaj workerzy mogą wziąć ten sam element lub wolny worker kontynuować po wygaśnięciu blokady. Przejmij pracę atomową dzierżawą z właścicielem, czasem i terminem. Przed wysłaniem potwierdź własność i brak zaakceptowanego zdalnego zadania. Zapisz ID transakcją lub warunkową aktualizacją, która nie powiedzie się, jeśli inny worker posunął stan. Używaj fencing tokenów, gdy stary worker może pisać. Każda dzierżawa zwiększa wersję, a baza przyjmuje tylko najnowszą. ## Doprowadź webhooks i polling do zbieżności Zadania wideo są asynchroniczne, więc polling i webhook mogą zgłosić to samo. Ich handlery również muszą być idempotentne. Dedupikuj po ID zdarzenia i aktualizuj warunkowo: `processing` nie może cofnąć `complete`. Podwójne pobranie zapisuje pod deterministycznym kluczem tymczasowym, sprawdza checksum i zbiega się w jednym obiekcie. ```text odbierz zakończenie znajdź operację po zdalnym ID skopiuj wynik pod deterministyczny klucz zweryfikuj media i checksum zapisz trwały URI oznacz jako ukończone, jeśli jeszcze nie jest ``` Po awarii kolejny handler wznawia bez nowej generacji. ## Loguj dowody do audytu Zachowaj czas wysłania, typ timeoutu, hash, klucz, nagłówki, zdalny ID i decyzję o retry. Redaguj sekrety. | Wskaźnik | Co ujawnia | |---|---| | Nieznane wysłania | Niejednoznaczność sieci lub dostawcy | | Uzgodnione bez retry | Uniknięte duplikaty | | Chronione retry | Zachowanie idempotencji przy awarii | | Podejrzane duplikaty | Pozostałe ryzyko finansowe | | Powtórzony checksum | Ten sam lub ponowiony wynik | | Czas w unknown | Szybkość odzyskiwania | Alarmuj o wzroście nieznanych wyników przed podnoszeniem limitów. Regresja sieci z agresywnym retry szybko mnoży koszty. ## Ukryj zachowanie dostawcy za adapterem Aplikacja wielomodelowa powinna mieć jeden interfejs i flagi możliwości. Adapter zarządza schematem, idempotencją, wyszukiwaniem, mapowaniem stanów i wynikami. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) może zmniejszyć integrację tekstu, obrazu i wideo na jednej platformie zgodnej z OpenAI. Nadal sprawdzaj dokładny model i endpoint: zgodność nie jest uniwersalną gwarancją idempotencji asynchronicznej. Zwracaj wynik znormalizowany: przyjęto z ID, jawnie odrzucono lub nieznany. Nie zamieniaj wyjątków transportu na błędy dostawcy. ## Testuj niejednoznaczne przypadki celowo Ścieżka sukcesu nie dowodzi bezpieczeństwa. W stagingu wstrzykuj błędy przed wysłaniem, po wyjściu bajtów, po akceptacji, po odpowiedzi przed bazą i podczas webhooka. Przy idempotencji jedna operacja tworzy najwyżej jedno zdalne zadanie. Bez niej operacja ma wejść w `unknown`, zatrzymać automatyczne wysyłanie i pokazać dowody. Testuj równoczesnych workerów, wygasłe dzierżawy, opóźnione i powtórne webhooks, restarty i stary klucz z nowymi parametrami. Jest to tańsze niż odkrycie duplikatów na fakturze. ## Podsumowanie Zapobiegaj duplikatom, nadając każdemu wynikowi jeden trwały klucz i oddzielając operację od prób HTTP. Zapisuj intencję przed wysłaniem, używaj dokumentowanej idempotencji i traktuj timeout jako nieznany wynik wymagający uzgodnienia. Dzierżawy, warunkowe stany, idempotentne zakończenie i trwałe logi zmieniają retry w kontrolowane odzyskiwanie zamiast podwójnego zakupu. ## FAQ ### Czy timeout HTTP oznacza, że API nie utworzyło zadania? Nie. Dostawca mógł przyjąć żądanie i utworzyć zadanie, mimo że klient nie dostał odpowiedzi. Traktuj wynik jako nieznany do uzgodnienia. ### Co powinien oznaczać klucz idempotencji? Jeden zamierzony skutek, np. produkt, wersję szablonu, język, proporcję i wariant. Używaj go ponownie dla retry tej operacji, ale utwórz nowy dla rzeczywiście nowego wyniku. ### Czy ograniczenie unikalności bazy zapobiega wszystkim duplikatom? Zapobiega podwójnym operacjom lokalnym, ale samo nie powstrzyma dostawcy przed przyjęciem dwóch żądań. Połącz je z idempotencją lub uzgadnianiem. ### Czy klient powinien automatycznie ponawiać każdy timeout? Nie. Retry jest bezpieczny tylko, gdy żądanie jest idempotentne lub wynik dostawcy można ustalić. W innym przypadku ustaw stan nieznany i najpierw uzgodnij. ### Jak długo przechowywać rekordy idempotencji? Co najmniej przez okno retry, wyszukiwania dostawcy, sporu fakturowego i audytu. Dopasuj okres do dokumentowanego zachowania i ryzyka. ### Czy API zgodne z OpenAI gwarantuje jednakową idempotencję wszystkich modeli wideo? Nie. Zgodność może ujednolicić transport, ale asynchroniczne zadania i idempotencja mogą zależeć od modelu lub dostawcy. Sprawdź aktualną dokumentację.