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

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

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

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

كيف يمكن إعادة المحاولة بعد أن أبلغت مهمة المستند عن خطأ؟ استنتاج جملة واحدة

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

حدد أولاً ما إذا كانت إعادة المحاولة ستؤدي إلى إنشاء مهام مكررة.

تعد مهلات POST مزعجة بشكل خاص. إذا لم يتلق العميل استجابة، فهذا لا يعني أن الخادم لم يقم بإنشاء مهمة. إذا لم تكن الواجهة تحتوي على مفاتيح مستقلة ولا تحتوي على آلية استعلام عن المهام، فقد تؤدي إعادة الإرسال الأعمى إلى إنشاء مهام ترجمة متعددة.

ولذلك، يجب أن تتبع استراتيجية إعادة المحاولة أولاً عقد الواجهة بدلاً من مجرد النظر إلى رمز حالة HTTP.

اكتب عدد المرات وميزانية الانتظار كوظائف خالصة

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

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

تحتاج بيئات الإنتاج أيضًا إلى مراعاة النقاط التالية:

• تم إرجاع Retry-After بواسطة الخادم
• ارتعاش عشوائي لتجنب استئناف عدد كبير من المهام في نفس الوقت
• الموعد النهائي الشامل
• الحد من عدد التزامنات

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

أنواع الأخطاء تتوافق مع إجراءات مختلفة

حفظ المهام المنطقية وسجلات المحاولات

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

ميزة هذا النهج هي وجود سجل كامل عند استكشاف مشاكل إعادة المحاولة، ولا يخطئ عدد المحاولات في احتساب كعدد طلبات المستخدمين.

📊 مقارنة النواة

استقرار تجربة الترجمة يأتي من شروحات واضحة

عند الاتصال ب OmniDoc، يجب أن يعلم الواجهة الأمامية المستخدمين بوضوح بالحالة الحالية: سواء كانوا ينتظرون، أو يحتاجون إلى إعادة تفويض، أو بحاجة لفحص حسابهم. لا تعرض كل الحالات ك "يولد".

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

المراجع: Python enum.

🎯 أي طريقة تناسبك؟

إذا كنت تنتظر استئناف الخدمة

استخدم التراجع المحدود، وحدد الحد الأقصى للعدد ووقت الانتظار الكلي، واحترمRetry-After الخاص بالخادم.

إذا واجهت مشاكل في الإذن أو الحساب

أوقف إعادة المحاولة التلقائية، وطلب من المستخدمين إعادة التفويض أو تحقق من حالة الحساب.

إذا كان هيكل ملف الإدخال غير صحيح

اطلب من المستخدمين إصلاح الملفات قبل التقديم، ولا تعيد إرسال نفس الملف.

إذا كانت الواجهة التي تتصل بها هي POST وقد تنتهي المهلة،

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

❓ الأسئلة الشائعة (الأسئلة الشائعة)

1. هل يمكن إعادة محاولة جميع الأخطاء مباشرة؟

لا، لا يمكنك. يجب التعامل مع أخطاء الأذون، وزيادات الحساب، وتلف الملفات، وتشغيل الخدمة المؤقت بشكل منفصل؛ فقط الأعطال المؤقت مناسبة للتجنب المحدود.

2. هل يمكنني إعادة النشر بعد انتهاء مهلة POST؟

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

3. كيف يجب تحديد عدد المحاولات المتكررة وأوقات الانتظار؟

الثواني الثابتة واحدة واثنتان وأربع ثوان مخصصة فقط لعرض التوليف (synthesis). يجب تحديد بيئة الإنتاج من خلال دمج Retry-After، التذبذب العشوائي، وقت القطع الكلي، وقيود التزامن.

4. هل سيؤثر عدد المحاولات على إحصائيات طلبات المستخدمين؟

لا، فقط سجل عملية مستخدم واحدة كمهمة منطقية وكل محاولة إعادة محاولة تحت تلك المهمة.

📝 ملخص

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

اختبر الآن: ارفع مستندك لتبدأ الترجمة، مع الحفاظ على التنسيق الأصلي