<!-- Canonical URL: https://ask.atlascloud.ai/ar/avoid-duplicate-video-jobs-api-timeout -->

# كيف تتجنب مهام الفيديو المكررة عند انتهاء مهلة طلب API؟

> امنع مهام الفيديو المكررة بمنح كل مخرج مقصود مفتاح عملية ثابتًا، وحفظ الطلب قبل إرساله، واستخدام منع التكرار الموثق لدى المزود، ومطابقة نتائج المهلة الملتبسة قبل المحاولة. انتهاء المهلة يعني أن النتيجة مجهولة، لا أن المزود رفض المهمة.

<!-- Canonical URL: https://ask.atlascloud.ai/avoid-duplicate-video-jobs-api-timeout -->

# كيف تتجنب مهام الفيديو المكررة عند انتهاء مهلة طلب API؟

ينشئ انتهاء مهلة الإرسال نتيجة ملتبسة. فقد يكون الطلب فشل قبل الوصول إلى الخدمة، أو وصل ورُفض، أو أنشأ مهمة فيديو بعيدة لم يصل ردها إلى العميل. لذلك قد تحول المحاولة الفورية مقطعًا مقصودًا واحدًا إلى توليدين مدفوعين.

الحل هو طبقة عمليات تمنع التكرار حول واجهة الفيديو. أنشئ العملية المقصودة واحفظها أولًا، وامنحها مفتاحًا ثابتًا، وسجّل كل محاولة، واستخدم قدرة المزود الموثقة على منع التكرار أو البحث. وإذا تعذر إثبات النتيجة البعيدة، فانقل العملية إلى حالة مجهولة صريحة بدل اعتبارها فاشلة.

## عرّف أثرًا مقصودًا واحدًا

يجب أن يحدد مفتاح منع التكرار ما طلب المستخدم من النظام إنشاءه، لا محاولة HTTP منفردة. إذا نالت كل محاولة مفتاحًا جديدًا فلن يستطيع المزود تمييز الازدواج.

في سير الكتالوج يمكن تعريف العملية بواسطة:

* معرّف المنتج؛
* إصدار القالب الإبداعي؛
* بصمة وسائط المصدر؛
* إصدار الأمر؛
* اللغة؛
* نسبة الأبعاد؛
* اسم المتغير.

أنشئ تمثيلًا معياريًا بترتيب مفاتيح ثابت وقيم موحدة ثم كوّن بصمته. خزّن الأبعاد المقروءة بجانب البصمة. إذا طلب المستخدم توليدًا مستقلًا آخر عمدًا، فأنشئ عملية أو متغيرًا جديدًا حتى لو تطابق الأمر.

لا تستخدم UUID عشوائيًا مولدًا داخل حلقة المحاولات. أنشئ مفتاح العملية قبل أول طلب وأعد استخدامه حتى يبلغ الأثر المقصود حالة نهائية.

## احفظ قبل الإرسال

ينبغي لقاعدة البيانات المحلية معرفة العملية قبل بدء اتصال الشبكة. هذا هو مبدأ الكتابة المسبقة مطبقًا على آثار API.

يمكن أن يحتوي سجل العملية على:

| الحقل | الغرض |
|---|---|
| مفتاح العملية | يمنع القصد المحلي المكرر |
| بصمة الطلب | تثبت المعلمات المرسلة |
| الحالة | تميز المحضر والمرسل والمجهول والمكتمل |
| عدد المحاولات | يطبق سياسة محدودة |
| المزود والنموذج | يدعم المسار والمطابقة |
| معرّف المهمة البعيدة | يستأنف الاستعلام بلا إعادة إرسال |
| آخر خطأ | يحفظ سياق التشخيص |
| بصمة المخرج | تكشف الأصول المكررة أو المتغيرة |

ضع قيد فرادة على مفتاح العملية. يجب أن يلتقي عاملان يحاولان إنشاء العملية نفسها في سجل واحد. استلم السجل بتحديث ذري أو عقد حيازة قبل الإرسال.

## استخدم منع تكرار المزود كما هو موثق فقط

تقبل بعض الواجهات مفتاح منع تكرار أو رمز طلب وتعيد نتيجة أول طلب مقبول عند تكراره. هذا أقوى مسار حين تغطي الوثائق نقطة النهاية ومدة الاحتفاظ ومقارنة المعلمات وسلوك الخطأ.

تحقق من أربعة تفاصيل:

* هل تدعم نقطة توليد الفيديو المفتاح؟
* كم يحتفظ به المزود؟
* هل يُرفض المفتاح نفسه مع معلمات مختلفة؟
* هل تعيد المحاولات معرّف المهمة الأصلي؟

لا تفترض أن ترويسة مدعومة للمدفوعات أو طلبات النص المتزامنة تنطبق على مهام الفيديو غير المتزامنة. شكل الطلب المتوافق مع OpenAI لا يجعل إنشاء المهام الخاص بالمزود مانعًا للتكرار تلقائيًا.

## اعتبر المهلة نتيجة مجهولة

استخدم حالات تصف الأدلة:

| الحالة | الدليل | الإجراء التالي |
|---|---|---|
| `prepared` | السجل المحلي موجود والإرسال لم يبدأ | أرسل |
| `sending` | بدأ العامل الطلب | انتظر النتيجة أو المهلة |
| `accepted` | استُلم معرّف بعيد | استعلم |
| `unknown` | انتهت المهلة بلا نتيجة مؤكدة | طابق |
| `failed` | رفض المزود أو أنهى المهمة صراحة | طبّق سياسة الفشل |
| `complete` | المخرج مخزن دائمًا | أعد النتيجة الموجودة |

الفرق بين `unknown` و`failed` أساسي. استثناء الشبكة دليل عن اتصال العميل، لا عن عمل المزود بالضرورة.

أرفق مفتاح العملية المحلي ببيانات المزود إذا أتاحت الواجهة مرجع عميل أو كائن بيانات وصفية، ليصبح هناك عنصر ثابت للبحث لاحقًا.

## طابق قبل إعادة المحاولة

يفحص عامل المطابقة العملية المجهولة وفق الأدلة المتاحة:

1. تحقق مما إذا حفظت المحاولة الأصلية معرّفًا بعيدًا قبل التعطل.
2. استعلم لدى المزود بمفتاح منع التكرار أو مرجع العميل إن أمكن.
3. ابحث في قائمة محدودة بحسب وقت الإنشاء والنموذج وبصمة الطلب.
4. افحص أحداث webhook التي ربما وصلت بعد المهلة.
5. قارن أحداث الاستخدام أو الفوترة إذا ظهرت بسرعة مناسبة.
6. أعد المحاولة فقط عند إثبات عدم وجود مهمة أو عندما يجعل منع التكرار الموثق ذلك آمنًا.

المطابقة بالوقت والأمر وحدهما قد تعطي نتائج زائفة. استخدم عدة سمات وانقل التطابقات غير المؤكدة للمراجعة. إذا لم توفر الواجهة بحثًا أو ضمانًا، فقد تكون السياسة الصحيحة الانتظار أو قبول احتمال الازدواج أو طلب قرار بشري وفق التكلفة والموعد.

## افصل محاولات النقل عن محاولات العملية

تعيد مكتبات HTTP أخطاء الشبكة تلقائيًا أحيانًا. يفيد ذلك في القراءة الآمنة لكنه خطر في الإرسال ذي الأثر. عطّل إعادة POST العامة ما لم تكن العملية محمية بمفتاح ثابت والسلوك موثقًا.

استخدم عدادين:

* محاولات النقل لإرسال العملية المحمية نفسها؛
* محاولات التوليد لإنشاء مخرج بديل عمدًا بعد فشل نهائي أو رفض جودة.

تمثل هذه العدادات تكاليف مختلفة. يجب أن تلتقي محاولة النقل في المهمة البعيدة نفسها، بينما محاولة التوليد محاولة إبداعية جديدة مدفوعة لها هوية مستقلة مرتبطة بمهمة الإنتاج الأصلية.

## عالج تزامن العمال بعقد حيازة

ليست المهلة مصدر التكرار الوحيد. قد يختار عاملان العنصر نفسه، أو يواصل عامل بطيء بعد انتهاء قفله.

استلم العمل بعقد ذري يتضمن المالك ووقت الاكتساب والانتهاء. قبل الإرسال يؤكد العامل امتلاكه للعقد وعدم تسجيل مهمة بعيدة مقبولة. خزّن المعرّف البعيد في معاملة أو تحديث مشروط يفشل إذا تقدم عامل آخر بالحالة.

استخدم رموز عزل إذا كان العامل القديم يستطيع الكتابة. تزيد كل حيازة رقم الإصدار، ولا تقبل قاعدة البيانات التغييرات إلا من أحدث إصدار، ما يمنع العملية القديمة من استبدال نتيجة أحدث.

## اجعل webhooks والاستعلام تلتقي

مهام الفيديو غير متزامنة، وقد يبلغ الاستعلام وwebhook الانتقال نفسه. يجب أن تكون معالجاتهما مانعة للتكرار أيضًا.

أزل الأحداث المكررة بمعرّف حدث المزود، واجعل تحديثات الحالة مشروطة: لا يعيد حدث `processing` مهمة من `complete` إلى الخلف. يجب أن يكتب التنزيل المكرر إلى مفتاح مؤقت حتمي ويتحقق من البصمة ويلتقي في كائن نهائي واحد.

ينبغي أن يكون مسار الإكمال آمنًا عند تكراره:

```text
استقبل الإكمال
ابحث عن العملية بمعرّف المهمة البعيدة
انسخ المخرج إلى مفتاح تخزين حتمي
تحقق من الوسائط والبصمة
سجّل الرابط الدائم
علّم العملية مكتملة إن لم تكن كذلك
```

إن تعطلت أي خطوة يمكن للمعالج التالي الاستئناف دون توليد فيديو جديد.

## سجّل أدلة كافية لتدقيق التكرار

احتفظ لكل محاولة بالطوابع حول الإرسال ونوع المهلة وبصمة الطلب ومفتاح منع التكرار وترويسات المزود والمعرّف البعيد وقرار المحاولة، مع تنقيح الأسرار والبيانات الحساسة.

تتبع مؤشرات التشغيل:

| المؤشر | ما يكشفه |
|---|---|
| إرسالات مجهولة | التباس الشبكة أو المزود |
| مطابقة بلا محاولة | تكرارات جرى تجنبها |
| عدد المحاولات المحمية | سلوك منع التكرار وقت الفشل |
| مهام مكررة مشتبه بها | خطر مالي متبقٍ |
| بصمة مخرج مكررة | نتيجة مزود متكررة أو نفسها |
| الزمن في الحالة المجهولة | سرعة الاستعادة |

أنذر عند ارتفاع النتائج المجهولة قبل زيادة حدود المحاولة. فقد تضاعف مشكلة شبكة مع محاولات عدوانية التكلفة سريعًا.

## أخفِ سلوك المزود خلف محول

ينبغي لتطبيق متعدد النماذج تقديم واجهة إرسال داخلية واحدة مع أعلام قدرات المزود. يملك المحول مخطط النقطة وآلية منع التكرار والبحث وتوحيد الحالة واستخراج المخرج.

يمكن لـ [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) تقليل عمل التكامل للفرق التي تستخدم نماذج النص والصورة والفيديو عبر منصة متوافقة مع OpenAI. ومع ذلك تحقق من سلوك نموذج الفيديو ونقطة النهاية المحددين. لا تعد التوافقية وعدًا عالميًا بمنع تكرار المهام غير المتزامنة.

أعد نتيجة موحدة مثل مقبول مع معرّف بعيد أو رفض صريح أو مجهول. لا تختصر استثناءات النقل إلى فشل مزود داخل المحول.

## اختبر الحالات الملتبسة عمدًا

لا يثبت المسار السعيد أمان التكرار. في بيئة اختبار، احقن أعطالًا قبل الإرسال وبعد خروج البايتات وبعد قبول المزود وبعد استلام الرد قبل تحديث القاعدة وأثناء webhook.

لكل حالة، تأكد أن العملية المقصودة تنتج مهمة بعيدة واحدة على الأكثر عندما يدعم المزود منع التكرار. وعندما لا يدعمه، تأكد أنها تدخل `unknown` وتوقف إعادة الإرسال وتعرض أدلة كافية للسياسة.

اختبر أيضًا العمال المتزامنين والعقود المنتهية وwebhooks المتأخرة والمكررة وإعادة التشغيل وإعادة استخدام مفتاح قديم بمعلمات جديدة. هذه الاختبارات أرخص من اكتشاف التوليد المكرر في الفاتورة.

## الخلاصة

تجنب مهام الفيديو المكررة بمنح كل مخرج مقصود مفتاح عملية دائمًا وفصل العملية عن محاولات HTTP. احفظ القصد قبل الإرسال، واستخدم منع التكرار الموثق، وعامل المهلة كنتيجة مجهولة تحتاج مطابقة. مع عقود الحيازة والتغييرات المشروطة ومعالجات الإكمال المانعة للتكرار وسجلات المحاولات الدائمة، تصبح المحاولة استعادة مضبوطة بدل شراء مكرر عرضي.

## FAQ

### هل تعني مهلة HTTP أن واجهة الفيديو لم تنشئ مهمة؟

لا. ربما قبل المزود الطلب وأنشأ مهمة رغم أن العميل لم يتلق الرد. عامل النتيجة كمجهولة حتى تتم مطابقتها.

### ماذا ينبغي أن يمثل مفتاح منع التكرار؟

يجب أن يمثل أثرًا مقصودًا واحدًا، مثل منتج وإصدار قالب ولغة ونسبة أبعاد ومتغير. أعد استخدامه لمحاولات العملية نفسها، وأنشئ مفتاحًا جديدًا لمخرج جديد فعلًا.

### هل يمنع قيد فرادة قاعدة البيانات كل التكرارات؟

يمنع العمليات المحلية المكررة، لكنه لا يمنع بمفرده المزود من قبول طلبين. ادمجه مع منع التكرار لدى المزود أو عملية مطابقة.

### هل يجب على العميل إعادة كل طلب انتهت مهلته تلقائيًا؟

لا. تكون المحاولة التلقائية آمنة فقط إذا كان الطلب غير مكرر الأثر أو أمكن تحديد نتيجة المزود. وإلا ضع المهمة في حالة مجهولة وطابقها أولًا.

### كم ينبغي الاحتفاظ بسجلات منع التكرار؟

احتفظ بها على الأقل طوال نافذة المحاولة ونافذة بحث المزود ومدة نزاع الفاتورة وحاجة التدقيق. طابق المدة مع السلوك الموثق والمخاطر التجارية.

### هل تضمن واجهة متوافقة مع OpenAI سلوك منع تكرار واحدًا لكل نماذج الفيديو؟

لا. قد توحد التوافقية النقل، لكن إنشاء المهام غير المتزامن ودعم منع التكرار قد يظلان خاصين بالمزود أو النموذج. تحقق من وثائق نقطة النهاية الحالية.
