Skip to main content

تنسيق استجابة الخطأ

تُعد Chat Completions وResponses وMessages وGemini حدود بروتوكول عامة وليست واجهات Web. لا تُلف أخطاء البروتوكول الأصلي في غلاف Web مثل { success, data, error }. المثال التالي يخص أخطاء gateway المتوافقة مع OpenAI في Chat وResponses:
في أخطاء gateway المتوافقة مع OpenAI يظهر الحقلان message وtype، بينما code وparam وحقول الإرشاد اختيارية. تستخدم Messages وGemini عائلات الخطأ الأصلية الخاصة بهما. تُحفظ أخطاء validation القادمة من upstream عندما يمكن إعادتها بأمان؛ ولا يؤدي 400/422 حتمي إلى تبديل القناة، ولا تحدث إعادة المحاولة بعد تسليم أول بايت.

رموز حالة HTTP

أنواع الأخطاء

أخطاء المصادقة (401)

أخطاء الدفع (402)

أخطاء الوصول (403)

أخطاء التحقق (400)

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

أخطاء حد المعدل (429)

عند تجاوز حدود المعدل:
الرؤوس المضمنة:
يشير كل من ترويسة Retry-After وحقل retry_after إلى عدد الثواني الدقيق للانتظار قبل إعادة المحاولة.

الحِمل أكبر من المسموح (413)

عندما يتجاوز حجم الإدخال أو الملف الحدود:
الأسباب الشائعة:
  • ملف صورة كبير جدًا (الحد الأقصى 20MB)
  • ملف صوتي كبير جدًا (الحد الأقصى 25MB)
  • نص الإدخال يتجاوز طول سياق النموذج

أخطاء المزود الأعلى (502، 503)

عندما تفشل كل القنوات، تتضمن الاستجابة نماذج بديلة:

معالجة الأخطاء في Python

معالجة الأخطاء في JavaScript

أفضل الممارسات

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