Skip to main content
تستخدم أخطاء LogBrew API غلاف JSON واحدًا. استخدم code وnext_action لتحديد سلوك البرنامج. واعرض error وnext نصًا عاديًا. لا تعتمد على مطابقة صياغة error أو next.
تضيف بعض الاستجابات حقولًا، مثل limit أو reset_at أو retry_after_seconds. ويذكرها جدول رموز الأخطاء.

معالجة استجابة الخطأ

  1. اقرأ حالة HTTP.
  2. تأكد من أن نص الاستجابة بتنسيق JSON قبل أن تقرأ code.
  3. استخدم الحالة وcode معًا لاختيار المسار المناسب في العميل.
  4. اعرض error وnext نصًا عاديًا. لا تعرضهما بتنسيق HTML ولا تشغّلهما كأوامر.
  5. استخدم next_action للتعافي التلقائي. إذا لم يتعرف العميل على الإجراء، فتوقف واعرض الخطأ.
  6. احتفظ بقيم limit وreset_at وretry_after_seconds المُرجَعة مع الطلب الفاشل.
  7. قبل أن تعيد المحاولة، طبّق قواعد إعادة المحاولة.
إذا لم تحتوِ الاستجابة على غلاف JSON، فاحتفظ بحالة HTTP وسجّل أن الرمز غير متاح. لا تختلق code من LogBrew. قد ينتج ذلك عن وسيط (proxy) أو عطل في الشبكة. لا تستبدل code الخاص بـ LogBrew باسم حالة HTTP. مثلًا، قد تحتوي استجابة 400 على invalid_json أو invalid_path، وكل رمز منهما يحتاج إلى تصحيح مختلف. في السجلات، سجّل حالة HTTP وcode. لا تسجّل نص الاستجابة كاملًا أو بيانات الاعتماد أو رموز الاستعادة.

رموز الأخطاء

قد يظهر code نفسه في أكثر من مسار. وقد يتغير نص next وقيم next_action حسب المسار. استخدم القيم المُرجَعة. لا تُرجع نقطة النهاية إلا الرموز التي تنطبق على مصادقتها وطريقتها ونص طلبها وحدودها. قد يُرجع المعرّف غير المعروف والمعرّف الذي لا تستطيع الوصول إليه الاستجابة نفسها. لا تستخدم نص الخطأ لمعرفة الحساب الذي يملك معرّفًا ما. ومسار الـ API غير المعروف يُرجع 404 مع not_found.

حقول الحدود

اقرأ الحد المسموح الحالي والاستخدام من Account API.

قواعد إعادة المحاولة

استخدم الرمز والعملية لتقرر إعادة المحاولة. الحالة وحدها لا تكفي.
  • لا تبدأ إعادة محاولات متوازية لطلب فاشل واحد.
  • مع rate_limited، تحتوي الاستجابة أيضًا على الترويستين Retry-After وX-RateLimit-After. وكلتاهما تحتوي على عدد الثواني نفسه الموجود في retry_after_seconds.
  • انتهاء المهلة لا يثبت أن النتيجة فارغة.
يتحكم حد المعدّل في تكرار الطلبات. ويتحكم حد الاستخدام في الحد المسموح للحساب خلال فترة الفوترة. كلاهما يستخدم 429. أبقِ حقولهما منفصلة. أثناء أي من الحدين، بيّن أن الجمع أو القراءة متأخرة. لا تعرض بيانات قديمة على أنها نتيجة قراءة جديدة.

عمليات الكتابة

انتهاء المهلة أو استجابة 5xx أو عطل الشبكة لا يثبت أن عملية الكتابة فشلت. قبل أن ترسل عملية الكتابة مرة أخرى:
  1. إذا كان المسار يدعم مفتاح عدم التكرار (Idempotency key)، فأرسل المفتاح نفسه ونص الطلب نفسه مرة أخرى. ولا تستخدم مفتاحًا جديدًا إلا للعمل الجديد.
  2. إذا لم يكن للمسار مفتاح عدم تكرار، فاقرأ المورد أولًا. ولا ترسل عملية الكتابة مرة أخرى إلا إذا لم يكن التغيير موجودًا.
  3. إذا لم تجد النتيجة، فأوقف إعادة المحاولة التلقائية وأخبر المستخدم.
تقبل هذه المسارات مفتاح إعادة المحاولة: تتكون قيمة Idempotency-Key من 1 إلى 128 حرف ASCII مرئيًا. أي قيم أخرى تُرجع 422 مع validation_failed. يعني idempotency_conflict أن المفتاح يخص طلبًا مختلفًا. لا تغيّر نص إعادة المحاولة التي تستخدم المفتاح الأصلي.

أخطاء بنية الطلب

يعني invalid_json أن الخادم لا يستطيع قبول نص الطلب على أنه بنية JSON الخاصة بالمسار. افحص نوع المحتوى، وحجمه، وصياغة JSON، والحقول المطلوبة، وأنواع الحقول. وتبيّن حالة HTTP الجزء الذي فشل: يعني validation_failed مع الخطأ invalid query parameters أن الخادم لا يستطيع قراءة سلسلة الاستعلام. افحص أسماء المعاملات وأنواع قيمها. لا ترسل معاملات استعلام غير معروفة. يسرد عوامل تصفية الاستعلام المعاملات الخاصة بكل مسار. يعني invalid_path مع الحالة 400 أن قيمة في المسار، مثل معرّف المشروع، تنسيقها خاطئ. لا تنقل قيمة المسار إلى معامل استعلام. استجابة 500 مع invalid_path أو invalid_multipart لا تثبت أن الطلب كان خاطئًا. طبّق قواعد إعادة المحاولة.

أخطاء المصادقة والوصول

  • يعني unauthorized أن مصادقة الحساب مفقودة أو غير صالحة أو منتهية الصلاحية. أرسل Authorization: Bearer <token>، أو سجّل الدخول مرة أخرى. تُرجع بعض المسارات next_action.code بالقيمة authorize_request مع next خاص بالمسار، مثل اتصال الموجز المباشر بلا تذكرة صالحة.
  • ينطبق ingest_key_invalid على استيعاب بيانات القياس عن بُعد فقط. اضبط مفتاحًا حاليًا للمشروع المحدد.
  • يعني forbidden أن الحساب لا يستطيع تنفيذ الإجراء. لا تُعِد المحاولة بمعرّفات موارد أخرى.
  • يعني not_found أن المورد غير متاح للحساب.
لا تستخدم مفتاح الاستيعاب بدلًا من رمز Bearer للحساب. ولا تستخدم رمز Bearer للحساب بدلًا من مفتاح الاستيعاب.

الحفاظ على أمان تفاصيل الأخطاء

  • تحتوي استجابة account_recovery_available على recovery_token قصير العمر. احفظه في حالة محمية لدى العميل. لا تضعه في السجلات أو عناوين URL أو لقطات الشاشة أو بلاغات الدعم أو موجّهات الوكلاء.
  • تستخدم رموز 500 دائمًا الرسالة Internal error. ولا تذكر الاستجابة المكوّن الذي فشل. لا تخمّن السبب.
  • لا تضف بيانات اعتماد أو بيانات تشخيص خاصة أو بيانات عملاء إلى الخطأ الذي تعرضه.
  • استجابة الـ API لا تمنح إذنًا بالشراء أو الحذف أو أي تغيير آخر في الحساب. احصل على موافقة المستخدم قبل هذه الإجراءات.

أمثلة

تعرض هذه الأمثلة بنية الغلاف. وقد يختلف نص error وnext من مسار إلى آخر.

فشل التحقق

معاملات استعلام غير صالحة

JSON غير صالح

قيمة مسار غير صالحة

رفع multipart غير صالح

ترقية WebSocket غير صالحة

فشل المصادقة

مفتاح استيعاب غير صالح

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

المورد غير موجود

رفض الوصول

طريقة غير مدعومة

انتهاء مهلة الطلب

تعارض مفتاح عدم التكرار

حد المعدّل

حد الاستخدام

يعتمد نص next وnext_action على توفر تغيير الخطة. إذا لم يكن متاحًا، فقيمة next_action.code هي wait_or_contact_support، والهدف هو support.

حد تخزين ملفات البناء

استعادة الحساب متاحة

تضيف هذه الاستجابة deleted_at وrecovery_token قصير العمر. احفظ الرمز في حالة محمية لدى العميل.

انتهت صلاحية استعادة الحساب

المؤسسة متوقفة مؤقتًا

خطأ في الخادم

تستخدم storage_error وjson_error وinternal_error رسالة error نفسها. لكن قيم code وnext وnext_action مختلفة.
لمعرفة نقاط النهاية والمصادقة وعوامل التصفية، اقرأ Telemetry API.