# Bagaimana Mencegah Pekerjaan Video Duplikat Saat Permintaan API Mengalami Timeout? > Cegah pekerjaan video duplikat dengan memberi setiap output yang dimaksud satu operation key stabil, menyimpan permintaan sebelum mengirim, menggunakan idempotency penyedia yang terdokumentasi jika tersedia, dan merekonsiliasi timeout ambigu sebelum mencoba lagi. Timeout berarti hasil belum diketahui, bukan bahwa penyedia menolak pekerjaan. # Bagaimana Mencegah Pekerjaan Video Duplikat Saat Permintaan API Mengalami Timeout? Timeout saat pengiriman menciptakan hasil ambigu. Permintaan mungkin gagal sebelum mencapai layanan, mencapai layanan tetapi ditolak, atau sudah membuat pekerjaan video jarak jauh sementara respons tidak pernah kembali ke client. Karena itu, retry langsung dapat mengubah satu klip yang dimaksud menjadi dua pembuatan berbayar. Solusinya adalah lapisan operation idempotent di sekitar API video. Buat dan simpan operation yang dimaksud lebih dulu, beri kunci stabil, catat setiap percobaan, dan gunakan kemampuan idempotency atau lookup yang terdokumentasi. Jika hasil jarak jauh tidak dapat dibuktikan, pindahkan operation ke status `unknown` eksplisit daripada berpura-pura bahwa ia gagal. ## Tentukan satu efek yang dimaksud Idempotency key harus mengidentifikasi apa yang diminta pengguna untuk dibuat sistem. Kunci tidak boleh mengidentifikasi satu percobaan HTTP. Jika setiap retry memperoleh kunci baru, penyedia tidak dapat mengenali duplikat. Untuk alur katalog, satu operation dapat ditentukan oleh: * ID produk; * versi template kreatif; * fingerprint media sumber; * versi prompt; * locale; * rasio aspek; * nama varian. Buat representasi kanonis dengan urutan kunci stabil dan nilai ternormalisasi, lalu hash. Simpan dimensi yang mudah dibaca di samping hash. Pengguna yang sengaja meminta pembuatan independen lain harus membuat operation atau varian baru, walaupun prompt kebetulan sama. Jangan gunakan UUID acak yang dibuat di dalam loop retry. Buat operation key sebelum permintaan pertama dan gunakan kembali sampai efek yang dimaksud mencapai status terminal. ## Simpan sebelum mengirim Basis data lokal harus mengetahui operation sebelum panggilan jaringan dimulai. Ini adalah prinsip write-ahead yang diterapkan pada efek samping API. Catatan operation dapat mencakup: | Bidang | Tujuan | |---|---| | Operation key | Mencegah niat lokal duplikat | | Request hash | Membuktikan parameter yang dikirim | | Status | Membedakan prepared, sent, unknown, dan complete | | Jumlah percobaan | Menerapkan kebijakan retry terbatas | | Penyedia dan model | Mendukung routing dan rekonsiliasi | | Remote job ID | Melanjutkan polling tanpa pengiriman ulang | | Kesalahan terakhir | Mempertahankan konteks diagnostik | | Output checksum | Mendeteksi aset duplikat atau berubah | Gunakan unique constraint pada operation key. Dua worker yang mencoba membuat operation sama harus bertemu pada satu catatan. Klaim catatan dengan pembaruan atomik atau lease sebelum worker mengirim permintaan. ## Gunakan idempotency penyedia hanya sesuai dokumentasi Sebagian API menerima idempotency key atau request token dan mengembalikan hasil permintaan pertama yang diterima ketika kunci sama dikirim ulang. Ini jalur terkuat jika dokumentasi jelas mencakup endpoint, periode retensi, perbandingan parameter, dan perilaku kesalahan. Verifikasi empat hal: * apakah endpoint pembuatan video mendukung kunci; * berapa lama penyedia mengingatnya; * apakah kunci sama dengan parameter berbeda ditolak; * apakah retry mengembalikan remote job ID asli. Jangan berasumsi header yang didukung untuk pembayaran atau permintaan teks sinkron juga berlaku pada pekerjaan video asinkron. Bentuk permintaan kompatibel OpenAI tidak otomatis membuat pembuatan pekerjaan spesifik penyedia menjadi idempotent. ## Perlakukan timeout sebagai hasil yang belum diketahui Gunakan status yang menjelaskan bukti, bukan harapan. | Status | Bukti | Tindakan berikutnya | |---|---|---| | `prepared` | Catatan lokal ada, pengiriman belum dimulai | Kirim | | `sending` | Worker memulai permintaan | Tunggu hasil atau timeout | | `accepted` | Remote job ID diterima | Poll | | `unknown` | Timeout tanpa hasil terkonfirmasi | Rekonsiliasi | | `failed` | Penyedia menolak jelas atau pekerjaan berakhir gagal | Terapkan kebijakan kegagalan | | `complete` | Output tersimpan permanen | Kembalikan hasil yang ada | Perbedaan antara `unknown` dan `failed` sangat penting. Network exception adalah bukti tentang koneksi client, bukan selalu tentang pekerjaan penyedia. Lampirkan operation key lokal ke metadata penyedia jika API menyediakan client reference atau objek metadata. Daftar pekerjaan atau permintaan dukungan berikutnya pun memiliki sesuatu yang stabil untuk dicari. ## Rekonsiliasi sebelum retry Worker rekonsiliasi menyelidiki operation unknown. Bukti yang tersedia bergantung pada penyedia, tetapi urutannya harus disengaja. 1. Periksa apakah percobaan awal menyimpan remote job ID sebelum proses gagal. 2. Cari pada penyedia dengan idempotency key atau client reference jika didukung. 3. Telusuri daftar pekerjaan terbatas memakai waktu pembuatan, model, dan request fingerprint. 4. Periksa event webhook yang mungkin tiba setelah client timeout. 5. Bandingkan event penagihan atau penggunaan jika muncul cukup cepat. 6. Retry hanya ketika sistem dapat membuktikan tidak ada pekerjaan atau idempotency terdokumentasi membuatnya aman. Pencocokan berdasarkan waktu dan prompt saja dapat menghasilkan false positive. Gunakan beberapa atribut dan tandai kecocokan tidak pasti untuk ditinjau. Jika API tidak memiliki lookup dan jaminan idempotency, kebijakan yang tepat mungkin menunggu, menerima kemungkinan duplikat, atau meminta keputusan manusia berdasarkan biaya klip dan tenggat. ## Pisahkan retry transport dari retry operation Library HTTP sering mencoba ulang kesalahan jaringan secara otomatis. Ini membantu pembacaan aman tetapi berisiko untuk pengiriman berefek samping. Nonaktifkan retry POST generik kecuali operation dilindungi idempotency key stabil dan endpoint mendokumentasikan perilakunya. Gunakan dua penghitung: * transport attempts untuk mengirim operation terlindungi yang sama; * generation attempts untuk sengaja membuat output pengganti setelah kegagalan terminal atau penolakan kualitas. Keduanya mewakili biaya berbeda. Retry transport harus bertemu pada remote job yang sama. Retry pembuatan adalah percobaan kreatif baru yang dapat ditagih dan memerlukan identitas percobaan baru, meskipun tetap terhubung ke pekerjaan produksi asli. ## Tangani worker bersamaan dengan lease Timeout bukan satu-satunya sumber duplikat. Dua worker dapat mengambil item antrean yang sama, atau worker lambat dapat terus berjalan setelah lock kedaluwarsa. Klaim pekerjaan dengan lease atomik berisi pemilik, waktu diperoleh, dan kedaluwarsa. Sebelum mengirim, worker mengonfirmasi masih memiliki lease dan belum ada remote job accepted yang tercatat. Simpan remote job ID dalam transaksi atau compare-and-set update yang gagal jika worker lain sudah memajukan operation. Gunakan fencing token jika worker lama masih bisa menulis. Setiap pengambilan lease menaikkan versi. Basis data hanya menerima perubahan status dari versi terbaru, sehingga proses lama tidak dapat menimpa hasil baru. ## Rancang webhook dan polling agar berkonvergensi Pekerjaan video bersifat asinkron, sehingga polling dan webhook dapat melaporkan transisi yang sama. Handler keduanya juga harus idempotent. Deduplicasikan event webhook dengan event ID penyedia jika ada. Buat pembaruan status bersyarat: event `processing` tidak boleh memundurkan pekerjaan dari `complete`. Mengunduh output yang sama dua kali harus menulis ke temporary key deterministik, memverifikasi checksum, dan berkonvergensi pada satu objek akhir. Jalur penyelesaian harus aman untuk diulang: ```text terima completion cari operation berdasarkan remote job ID salin output ke storage key deterministik verifikasi media dan checksum catat URI permanen tandai operation complete jika belum complete ``` Jika langkah mana pun crash, handler berikutnya dapat memulai ulang tanpa membuat video baru. ## Catat bukti yang cukup untuk mengaudit duplikat Untuk setiap percobaan, simpan timestamp di sekitar pengiriman, jenis timeout, request hash, idempotency key, header respons penyedia, remote ID, dan keputusan retry. Redaksi credential dan data prompt sensitif. Pantau metrik operasional: | Metrik | Yang diungkapkan | |---|---| | Pengiriman unknown | Ambiguitas jaringan atau penyedia | | Direkonsiliasi tanpa retry | Duplikat yang berhasil dihindari | | Jumlah retry terlindungi | Perilaku idempotency saat gagal | | Pekerjaan diduga duplikat | Risiko finansial yang tersisa | | Output checksum duplikat | Hasil penyedia yang sama atau berulang | | Waktu dalam status unknown | Kecepatan pemulihan | Buat peringatan saat hasil unknown meningkat tidak biasa sebelum sekadar menaikkan batas retry. Regresi jaringan yang digabung dengan retry agresif dapat menggandakan biaya dengan cepat. ## Tempatkan perilaku penyedia di balik adapter Aplikasi multi-model harus menyediakan satu antarmuka pengiriman internal dengan capability flag penyedia. Adapter menangani schema endpoint, mekanisme idempotency, lookup pekerjaan, pemetaan status, dan ekstraksi output. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) dapat mengurangi pekerjaan integrasi bagi tim yang memakai model teks, gambar, dan video melalui satu platform kompatibel OpenAI. Namun, verifikasi perilaku terbaru dari model dan endpoint video yang tepat. Kompatibilitas menormalkan banyak pola permintaan, tetapi bukan janji universal tentang idempotency pekerjaan asinkron. Kembalikan hasil ternormalisasi seperti accepted dengan remote ID, penolakan eksplisit, atau unknown. Jangan menyamakan transport exception dengan kegagalan penyedia dalam adapter. ## Uji kasus ambigu secara sengaja Happy path tidak membuktikan keamanan duplikat. Dalam staging, injeksikan kegagalan sebelum mengirim, setelah byte meninggalkan client, setelah penyedia menerima, setelah respons diterima tetapi sebelum pembaruan basis data, dan selama pengiriman webhook. Untuk setiap kasus, pastikan satu operation yang dimaksud menghasilkan tidak lebih dari satu remote job ketika penyedia mendukung idempotency. Jika tidak, pastikan operation masuk `unknown`, menghentikan pengiriman ulang otomatis, dan mengekspos cukup bukti untuk kebijakan yang dipilih. Uji juga worker bersamaan, lease kedaluwarsa, webhook terlambat dan berulang, restart proses, serta penggunaan ulang kunci lama dengan parameter berubah. Pengujian ini lebih murah daripada menemukan pembuatan duplikat melalui invoice. ## Kesimpulan Hindari pekerjaan video duplikat dengan memberi setiap output yang dimaksud satu operation key permanen dan memisahkan operation itu dari percobaan HTTP. Simpan niat sebelum mengirim, gunakan idempotency terdokumentasi, dan perlakukan timeout sebagai hasil unknown yang harus direkonsiliasi. Dengan lease, perubahan status bersyarat, completion handler idempotent, dan log percobaan permanen, retry menjadi pemulihan terkontrol alih-alih pembelian ulang yang tidak disengaja. ## FAQ ### Apakah HTTP timeout berarti API video tidak membuat pekerjaan? Tidak. Penyedia mungkin telah menerima permintaan dan membuat pekerjaan meskipun client tidak menerima respons. Perlakukan hasil sebagai tidak diketahui sampai direkonsiliasi. ### Apa yang harus diwakili idempotency key? Kunci harus mewakili satu efek yang dimaksud, seperti satu produk, versi template, locale, rasio aspek, dan varian. Gunakan kembali untuk retry operation itu, tetapi buat kunci baru untuk output yang benar-benar baru. ### Apakah unique constraint basis data dapat mencegah semua duplikat? Constraint mencegah operation lokal duplikat, tetapi tidak dapat sendirian mencegah penyedia menerima dua permintaan. Gabungkan dengan idempotency penyedia atau proses rekonsiliasi. ### Haruskah client otomatis mencoba ulang setiap timeout? Tidak. Retry otomatis hanya aman ketika permintaan bersifat idempotent atau hasil penyedia dapat ditentukan. Jika tidak, tempatkan pekerjaan dalam status unknown dan rekonsiliasi lebih dulu. ### Berapa lama catatan idempotency harus dipertahankan? Setidaknya selama jendela retry, jendela pencarian penyedia, periode sengketa tagihan, dan kebutuhan audit operasional. Sesuaikan dengan perilaku penyedia yang terdokumentasi dan risiko bisnis. ### Apakah API kompatibel OpenAI menjamin perilaku idempotency yang sama di semua model video? Tidak. Kompatibilitas dapat menormalkan transport, tetapi pembuatan pekerjaan asinkron dan dukungan idempotency tetap dapat spesifik terhadap model atau penyedia. Periksa dokumentasi endpoint terbaru.