# API isteği zaman aşımına uğradığında yinelenen video işleri nasıl önlenir? > Her hedef çıktıya kararlı operasyon anahtarı vererek, isteği göndermeden saklayarak, belgeli sağlayıcı idempotency'sini kullanarak ve retry öncesi belirsiz timeout'u uzlaştırarak yinelenen işleri önleyin. Timeout bilinmeyen sonuç demektir, ret değil. # API isteği zaman aşımına uğradığında yinelenen video işleri nasıl önlenir? Gönderim zaman aşımı belirsiz sonuç yaratır. İstek servise ulaşmadan başarısız olmuş, ulaşıp reddedilmiş veya yanıtı client'a dönmeyen bir remote iş oluşturmuş olabilir. Hemen retry etmek tek klibi iki ücretli üretime çevirebilir. Çözüm video API'sinin etrafındaki idempotent operasyon katmanıdır. Önce hedef operasyonu oluşturup saklayın, kararlı anahtar verin, her denemeyi kaydedin ve belgeli idempotency ya da arama özelliğini kullanın. Remote sonuç kanıtlanamazsa operasyonu açıkça unknown durumuna taşıyın. ## Tek hedef yan etkiyi tanımlayın Anahtar kullanıcı adına oluşturulacak şeyi tanımlamalıdır, tek HTTP denemesini değil. Her retry yeni anahtar alırsa sağlayıcı yinelenmeyi anlayamaz. Katalog operasyonu şunlarla tanımlanabilir: * ürün ID'si; * yaratıcı şablon sürümü; * kaynak medya parmak izi; * prompt sürümü; * locale; * en-boy oranı; * varyant adı. Sabit sıra ve normalize değerlerle kanonik gösterim oluşturup hash alın. Okunabilir boyutları yanında saklayın. Kullanıcı bağımsız yeni üretim isterse prompt aynı olsa bile yeni operasyon veya varyant oluşturun. Retry döngüsünde rastgele UUID üretmeyin. Anahtarı ilk istekten önce üretin ve terminal duruma kadar kullanın. ## Göndermeden önce saklayın Yerel veritabanı ağ çağrısından önce operasyonu bilmelidir. Bu API yan etkilerine write-ahead ilkesidir. | Alan | Amaç | |---|---| | Operasyon anahtarı | Yinelenen yerel niyeti önler | | İstek hash'i | Gönderilen parametreleri kanıtlar | | Durum | Prepared, sent, unknown ve complete'i ayırır | | Deneme sayısı | Sınırlı politika uygular | | Sağlayıcı ve model | Rota ve uzlaştırma destekler | | Remote iş ID'si | Yeniden göndermeden polling sürdürür | | Son hata | Tanı bağlamını korur | | Çıktı checksum'u | Yinelenen ya da değişen varlığı saptar | Anahtara benzersizlik kısıtı koyun. Aynı operasyonu yaratan iki worker tek kayıtta birleşsin. Gönderimden önce atomik güncelleme veya lease ile alın. ## Sağlayıcı idempotency'sini yalnızca belgelendiği gibi kullanın Bazı API'ler anahtar kabul eder ve aynı anahtar yinelendiğinde ilk kabul edilen sonucu döndürür. Belgeler endpoint, saklama süresi, parametre karşılaştırması ve hata davranışını kapsıyorsa en güçlü yoldur. Şunları doğrulayın: * video endpoint anahtarı destekliyor mu; * sağlayıcı ne kadar hatırlıyor; * aynı anahtar farklı parametreyle reddediliyor mu; * retry ilk remote ID'yi döndürüyor mu. Ödeme veya senkron metin header'ının asenkron videoda da geçerli olduğunu varsaymayın. OpenAI uyumlu biçim sağlayıcı işini otomatik idempotent yapmaz. ## Timeout'u bilinmeyen sonuç sayın | Durum | Kanıt | Sonraki eylem | |---|---|---| | `prepared` | Yerel kayıt var, gönderim başlamadı | Gönder | | `sending` | Worker isteği başlattı | Sonuç veya timeout bekle | | `accepted` | Remote ID alındı | Sorgula | | `unknown` | Onay olmadan timeout | Uzlaştır | | `failed` | Açık ret veya terminal hata | Hata politikasını uygula | | `complete` | Çıktı kalıcı saklandı | Mevcut sonucu döndür | `unknown` ile `failed` farkı kritiktir. Ağ istisnası client bağlantısı hakkında kanıttır, sağlayıcı işi hakkında değil. API metadata veya client reference sunarsa yerel anahtarı ekleyin; sonraki listede kararlı değer aranabilir. ## Retry öncesi uzlaştırın Uzlaştırma worker'ı bilinmeyen operasyonu inceler: 1. İlk deneme çökmeden remote ID kaydetmiş mi bakın. 2. Destekleniyorsa anahtar veya client reference ile sorgulayın. 3. Zaman, model ve parmak iziyle sınırlı iş listesi arayın. 4. Timeout sonrası gelen webhook olaylarını inceleyin. 5. Zamanında varsa kullanım veya fatura olaylarını karşılaştırın. 6. Yalnız iş yokluğu kanıtlandığında ya da idempotency güvenli kıldığında retry edin. Yalnız zaman ve prompt yanlış eşleşme üretir. Birden fazla özellik kullanın ve belirsiz eşleşmeyi review'a gönderin. Arama veya garanti yoksa doğru politika beklemek, olası yinelenmeyi kabul etmek veya insan kararı olabilir. ## Transport retry ile üretim retry'sini ayırın HTTP kütüphaneleri ağ hatalarını otomatik yineleyebilir. Güvenli okumada yararlı, yan etkili gönderimde risklidir. Operasyon kararlı anahtar ve belgeli davranışla korunmuyorsa genel POST retry'larını kapatın. İki sayaç kullanın: * aynı korunan operasyonun transport denemeleri; * terminal hata veya kalite reddinden sonra yeni çıktı üretim denemeleri. Transport retry aynı remote işe birleşmelidir. Üretim retry'si özgün üretim işiyle bağlı, kendi kimliği olan yeni ücretli yaratıcı denemedir. ## Eşzamanlı worker'ları lease ile yönetin Timeout tek yinelenme kaynağı değildir. İki worker aynı öğeyi alabilir veya yavaş worker kilit bittikten sonra devam edebilir. Sahip, başlangıç ve bitiş içeren atomik lease ile işi alın. Gönderimden önce sahipliği ve kabul edilmiş remote iş olmadığını doğrulayın. Remote ID'yi, başkası durumu ilerlettiyse başarısız olacak transaction veya koşullu güncellemeyle saklayın. Eski worker yazabiliyorsa fencing token kullanın. Her lease sürümü artırır; veritabanı yalnızca en yeniyi kabul eder. ## Webhook ve polling'i birleştirin Video işleri asenkrondur, polling ve webhook aynı geçişi bildirebilir. Handler'lar da idempotent olmalıdır. Event ID ile yinelenmeleri kaldırın ve koşullu güncelleyin: `processing`, `complete` işi geriye almamalı. İki indirme deterministik geçici anahtara yazıp checksum doğrular ve tek nesnede birleşir. ```text tamamlanmayı al remote ID ile operasyonu bul çıktıyı deterministik anahtara kopyala medya ve checksum'u doğrula kalıcı URI'yi kaydet zaten değilse complete işaretle ``` Bir adım çökerse sonraki handler yeni video üretmeden sürdürür. ## Denetim için yeterli kanıt loglayın Her denemede zaman, timeout türü, istek hash'i, anahtar, response header, remote ID ve retry kararı tutun. Sırları düzeltin. | Metrik | Gösterdiği | |---|---| | Bilinmeyen gönderimler | Ağ veya sağlayıcı belirsizliği | | Retry olmadan uzlaştırılan | Önlenen yinelenmeler | | Korumalı retry sayısı | Hata altında idempotency | | Şüpheli yinelenen iş | Kalan mali risk | | Yinelenen checksum | Aynı veya tekrarlı sonuç | | Unknown'da süre | Kurtarma hızı | Retry limitini artırmadan önce bilinmeyen sonuç artışına alarm verin. Ağ gerilemesi ve agresif retry maliyeti hızla çoğaltır. ## Sağlayıcı davranışını adaptör arkasında tutun Çok modelli uygulama yetenek bayrakları olan tek iç gönderim arayüzü sunmalıdır. Adaptör şema, idempotency, iş arama, durum eşleme ve çıktı çıkarma işini üstlenir. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) metin, görüntü ve video kullanan ekiplerde OpenAI uyumlu tek platformla entegrasyonu azaltabilir. Yine de kesin model ve endpoint davranışını doğrulayın; uyumluluk asenkron idempotency için evrensel söz değildir. Remote ID ile kabul, açık ret veya unknown gibi normalize sonuç döndürün. Transport istisnasını sağlayıcı hatasına çevirmeyin. ## Belirsiz durumları kasıtlı test edin Başarılı yol güvenliği kanıtlamaz. Staging'de gönderim öncesi, byte çıktıktan sonra, kabul sonrası, yanıttan sonra veritabanından önce ve webhook sırasında hata enjekte edin. Idempotency varsa bir operasyon en fazla bir remote iş üretmelidir. Yoksa `unknown` durumuna girip otomatik yeniden gönderimi durdurmalı ve kanıt göstermelidir. Eşzamanlı worker, bitmiş lease, gecikmiş ve yinelenen webhook, restart ve değişmiş parametreyle eski anahtarı test edin. Bunlar faturada yinelenme bulmaktan ucuzdur. ## Sonuç Her hedef çıktıya kalıcı operasyon anahtarı verip operasyonu HTTP denemelerinden ayırarak yinelenen video işlerini önleyin. Niyeti göndermeden saklayın, belgeli idempotency kullanın ve timeout'u uzlaştırılması gereken bilinmeyen sonuç sayın. Lease, koşullu durum, idempotent tamamlanma ve kalıcı loglar retry'ı yanlışlıkla çift satın alma yerine kontrollü kurtarma yapar. ## FAQ ### HTTP timeout video API'sinin iş oluşturmadığı anlamına mı gelir? Hayır. Client yanıtı almasa bile sağlayıcı isteği kabul edip iş oluşturmuş olabilir. Uzlaştırılana kadar sonucu bilinmeyen sayın. ### Idempotency key neyi temsil etmeli? Bir ürün, şablon sürümü, dil, oran ve varyant gibi tek hedef yan etkiyi. Aynı operasyonun retry'larında yeniden kullanın, gerçekten yeni çıktı için yeni anahtar üretin. ### Veritabanı benzersizlik kısıtı tüm yinelenmeleri önler mi? Yerel operasyonları önler, ancak sağlayıcının iki isteği kabul etmesini tek başına durdurmaz. Sağlayıcı idempotency veya uzlaştırma ile birleştirin. ### Client her timeout'u otomatik retry etmeli mi? Hayır. Yalnızca istek idempotentse veya sağlayıcı sonucu belirlenebiliyorsa güvenlidir. Aksi halde işi unknown durumuna alın ve önce uzlaştırın. ### Idempotency kayıtları ne kadar tutulmalı? En az retry penceresi, sağlayıcı arama süresi, fatura itirazı ve denetim ihtiyacı kadar. Süreyi belgeli davranış ve riskle eşleştirin. ### OpenAI uyumlu API tüm video modellerinde aynı idempotency'yi garanti eder mi? Hayır. Transport normalize olabilir, ancak asenkron iş oluşturma ve idempotency model veya sağlayıcıya özgü kalabilir. Güncel endpoint belgesini doğrulayın.