GH GambleHub

رموز معالجة الأخطاء والحالة

1) لماذا توحيد الأخطاء

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

2) مبادئ التصميم

1. مخطط خطأ واحد لجميع الخدمات (REST/GraphQL/gRPC/webooks).
2. دلالات واضحة من retrays: التي ترمز إلى التراجع، والتي لا.
3. فشل مغلق في عمليات الكتابة: 4xx/5xx أفضل من عدم الاتساق الهادئ.
4. لا توجد تسريبات: لا تكشف عن SQL، الأكوام، التكوينات، المعرفات الداخلية.
5. Trace - Track 'trace _ id '/' correlation _ id'.
6. توطين الرسائل اختياري، لكن الرموز و «reason» تظل مستقرة.


3) تنسيق واحد (تفاصيل المشكلة/JSON)

شكل الأساس الموصى به (مطابق لـ RFC 7807):
json
{
"type": "https://errors.example.com/auth/invalid-token",
"title": "Invalid access token",
"status": 401,
"code": "AUTH_INVALID_TOKEN",
"detail": "Token expired or signature invalid.",
"instance": "/api/v1/payments/12345",
"trace_id": "01HX3...ABC",
"hint": "Obtain a new token via OAuth2 refresh.",
"meta": {
"scope": "payments:write",
"policy": "deny-by-default"
}
}
تفسيرات:
  • 'نوع' هو مستقر فئة الخطأ URL.
  • «رمز» - رمز آلة النطاق القصير (مستقر بين الإصدارات).
  • «تلميح» - ماذا تفعل للعميل (تكرار، تحديث رمز، تغيير المعلمات).
  • «meta» - أجزاء آمنة (بدون أسرار و PII).

4) خريطة رمز الحالة (المجموعة الدنيا)

التوثيق/الإذن

400 طلب سيء - التحقق الهيكلي/المخطط.
401 غير مصرح به - لا/رمز غير صالح. أضف «WWW-Authenticate».
403 ممنوع - موثق ولكن لا توجد حقوق/سياسات محرومة.
404 غير موجود - إخفاء وجود مورد بدون حقوق.
409 Conflict - version/state conflict (optional lock, idempotency).
451 غير متوفر لأسباب قانونية - الامتثال/حظر الولاية القضائية.

الحدود والحماية

408 طلب مهلة - يرسل العميل الجثة ببطء شديد.
409/425 مبكر جدا - حظر التكرار المبكر في 0-RTT/TLS 1. 3.
429 طلبات كثيرة جدًا - مع «إعادة التجربة بعد» وسياسة الحد.
499 طلب العميل المغلق - (في المحيط/NGINX) قام العميل بفصل الاتصال.

قواعد البيانات والأعمال

422 محتوى غير قابل للاختبار - تم تمرير التحقق من صحة العمل في المخطط، لكن المعنى غير صحيح.
423 مقفلة - محظورة الموارد (مراجعة KYC، تجميد AML).
409 Conflict - double submission, race, status reduction (see, «access process»).
410 ذهب - نقطة النهاية/الموارد محذوفة (استنكاف كامل).

خادم

500 خطأ في الخادم الداخلي - خطأ غير معروف ؛ لا تفصح عن التفاصيل.
502 Bad Gateway - التبعية عادت خطأ/وكيل.
503 خدمات غير متوفرة - التدهور/العمل المقرر ؛ أضف «إعادة المحاولة بعد».
504 بوابة تايم أوت.

💡 القاعدة: اكتب العمليات بشك → 409 (نزاع) أو 503 (كرر لاحقًا)، وليس 200.

5) دلالات إعادة الدرس والغباء

لا يمكنك التراجع عن 400/ 401/403/404/422 (ما لم يغير العميل الطلب).
يمكنك التراجع: 408/429/5xx/ 425/499/504 (مع backoff + jitter).
Idempotency: For 'POST', enable' Idempotency-Key '(UUIDv4).

لإعادة المحاولة، أعد 409 مع «تلميح:» استخدم نفس مفتاح الخصوصية أو وضع GET «».
أضف «Idempotency-Replay: true» عند إعادة نتيجة محفوظة.

مثال الرؤوس عند 429:

HTTP/1.1 429 Too Many Requests
Retry-After: 3
RateLimit-Limit: 50
RateLimit-Remaining: 0
RateLimit-Reset: 1730641030

6) التحقق من صحة المدخلات: هيكل الخطأ الميداني

بالنسبة لـ 400/422، استخدم مجموعة من الأخطاء الميدانية:
json
{
"type": "https://errors.example.com/validation",
"title": "Validation failed",
"status": 422,
"code": "VALIDATION_ERROR",
"trace_id": "01HX4...XYZ",
"errors": [
{"field": "amount", "rule": "min", "message": "Must be >= 10"},
{"field": "currency", "rule": "enum", "message": "Unsupported currency"}
]
}

7) فشل جزئي (فشل جزئي/دفعة)

في نقاط نهاية الدفعة، لا تخفي الأخطاء داخل 200 بدون هيكل. إعادة 207 حالة متعددة أو 200 مع مجموعة من النتائج، حيث يكون لكل مهمة وضعها الخاص:
json
{
"status": "partial",
"succeeded": 8,
"failed": 2,
"results": [
{"id": "op1", "status": 201},
{"id": "op2", "status": 422, "error": {"code":"VALIDATION_ERROR","detail":"..."}}
]
}

8) التثبيت والإجابات «الفارغة»

المجموعة الفارغة - بنود 200: []، وليس 404.
نهاية الصفحة - «الصفحة التالية _ الرمز المميز» مفقود.
رمز غير صحيح - رمز 400: PAGINATION_CURSOR_INVALID'.


9) خطوط الويب: تسليم موثوق

وقع الأحداث (HMAC) وتحقق قبل المعالجة.
الاستجابة للمعالجة الناجحة هي 2xx (أفضل 204).
أعطال المتلقي المؤقتة - 5xx ؛ المرسل يكرر (تراجع أسي، رعشة).
التفريغ بواسطة 'event _ id' وحفظ النتيجة (المستهلك المغرور).
حمولة غير صالحة - 400/422 بدون إعادة.


10) مطابقة البروتوكول (gRPC/GraphQL)

gRPC → HTTP:
  • «غير صالح _ حجة» 400 →
  • 'غير مصرح به' → 401
  • «إذن _ رفض» → 403
  • «غير موجود» → 404
  • «موجود بالفعل» → 409
  • «شرط مسبق فاشل» → 412/422
  • 'الموارد _ المستنفدة' → 429
  • «أجهض» → 409
  • 'غير متاح' → 503
  • «الموعد النهائي _ تجاوز» → 504
الرسم البياني QL: دائمًا ما يكون 200 في طبقة النقل صحيحًا، ولكن ضع الأخطاء في «الأخطاء []» ومكررة في الرؤوس/الامتدادات:
json
{
"data": { "createPayment": null },
"errors": [{
"message": "Forbidden",
"extensions": { "code": "FORBIDDEN", "status": 403, "trace_id": "..." },
"path": ["createPayment"]
}]
}

يوصى باستخدام رمز HTTP المقابل بدلاً من 200 للأخطاء الحرجة.


11) العناوين ونصائح العملاء

«Retry-After» - ثانية/تاريخ HTTP (429/503/425/408).
«تحذير» - تدهور ناعم أو انتقاص («199 - الميزة X مكتئبة»).
'Deprecation', 'Sunset',' Link: <...>; rel = «الاستنكار» - للإغلاق الخاضع للرقابة.
«نوع المشكلة» (مخصص) - توجيه خطأ سريع على العميل.
'X-Trace-Id '/' Correlation-Id' - links logs/traces.


12) أمن الرسالة

لا تكرر أسرار الإدخال (الرموز/التوقيعات) في هيئة الاستجابة.
Mask PAN/PII ('1234').
مقابل 401/403 - لا تكشف عن السمة التي فشلت.
مقابل 404، بدلاً من «الموارد موجودة ولكن ليس لك» - 404 فقط.


13) إمكانية ملاحظة الأخطاء

المقاييس:
  • 'http _ أخطاء _ المجموع {الحالة، الطريق، المستأجر}'
  • «خطأ _ فئات _ إجمالي {رمز}» (بواسطة «رمز» من الجسم)
  • حصة 429، 5xx ؛ لوقت «p95 »/« p99» للإجابات الخاطئة بشكل منفصل
  • 'retry _ after _ seconds _ bucket' - مخطط هسيمي لنصائح التكرار
الجذوع/المسارات:
  • ربط الرد بـ "trace _ id" و "store" و "type" و "status' و" route "و" المستأجر "و" no PII ".
تنبيهات:
  • ارتفاع معدل 5xx> X٪ في RPS> N ؛
  • ونمو 429 على الطرق الحيوية ؛
  • «مهلة/504» للتبعيات ؛
  • 409/الخصوصية المتكررة → علامة على السباق.

14) أمثلة

14. 1 422 (التحقق من صحة الأعمال)

json
{
"type": "https://errors.example.com/payments/limit-exceeded",
"title": "Limit exceeded",
"status": 422,
"code": "PAYMENT_LIMIT_EXCEEDED",
"detail": "Daily withdrawal limit reached for KYC1.",
"hint": "Increase limits after KYC2 or try tomorrow.",
"trace_id": "01J5...XYZ"
}

14. 2 409 (الخصوصية)


HTTP/1.1 409 Conflict
Idempotency-Replay: true
json
{
"type": "https://errors.example.com/idempotency/replay",
"title": "Duplicate request",
"status": 409,
"code": "IDEMPOTENT_REPLAY",
"detail": "A request with the same Idempotency-Key was already processed.",
"hint": "Reuse the same Idempotency-Key and GET the operation status."
}

14. 3 429 (حدود)

json
{
"type":"https://errors.example.com/rate/too-many-requests",
"title":"Too many requests",
"status":429,
"code":"RATE_LIMITED",
"detail":"Per-key rate limit exceeded.",
"hint":"Retry after the time specified in Retry-After header."
}

15) أنتيباترن

إعادة 200 مع نص خطأ الجسم.
امزج تنسيقات خطأ مختلفة بين الخدمات.
توسيع المكدس/SQL/أسماء الجدول/عناوين URL الداخلية في «ذيل».
استخدم «رسالة» بدلاً من «رمز »/« نوع» مستقر.
العائد 500 عندما يحدث خطأ تجاري متوقع (على سبيل المثال، «الرصيد غير كاف»).
دلالات غير متسقة بين REST/GraphQL/gRPC.


16) تفاصيل iGaming/Finance

الرموز الواضحة لـ KYC/AML/العقوبات: 'KYC _ NEXT', 'KYC _ REVIEW', 'AML _ LOCK', 'SANCTION _ BLOCKED'.
القيود القضائية: 451 مع صياغة آمنة دون إدراج.
عمليات الكتابة النقدية: 409/423 للمنافسة والأقفال، «تلميح» مع نافذة إعادة.
ثوابت حد اللاعب: استخدم 422 لانتهاكات الدفع المسؤولة.
التدقيق: سجلات حلول غير قابلة للتغيير (رمز، وقت، ممثل، trace_id).


17) قائمة التحقق من الاستعداد

  • مخطط خطأ JSON واحد، «نوع »/« رمز» مستقر.
  • رسم خرائط HTTP ↔ gRPC/GraphQL متسق وموثق.
  • إعادة الدلالات + «إعادة المحاولة بعد» ؛ الفراغ للكتابة.
  • PII/القناع السري ؛ 404 لإخفاء الموارد.
  • مقاييس الخطأ والإنذار ؛ الارتباط مع 'trace _ id'.
  • استنكار السياسات: "Deprecation" و "Sunset' و" Link ".
  • الاختبارات: سلبية/زغب، نسخة تضارب، انخفاض التبعية، تقديم مزدوج.
  • دليل العملاء: أمثلة احتياطية ومعالجة 409/422/429/5xx.

18) TL ؛ د

قم بتوحيد تنسيق خطأ JSON واحد مع «نوع »/« رمز »/« تتبع _ id»، واستخدام رموز HTTP الصحيحة، والتمييز بين التحقق (400/422)، وحقوق (401/403/404)، والتضارب/الخصوصية (409)، والحدود (429). قم بإعطاء «Retry-After» و «تلميح» واضحين، وإخفاء البيانات الحساسة، وتسجيل الأخطاء مع «تتبع _ معرف» وبناء التنبيهات بحلول 5xx/429/p99.

Contact

اتصل بنا

تواصل معنا لأي أسئلة أو دعم.نحن دائمًا جاهزون لمساعدتكم!

بدء التكامل

البريد الإلكتروني — إلزامي. تيليغرام أو واتساب — اختياري.

اسمك اختياري
البريد الإلكتروني اختياري
الموضوع اختياري
الرسالة اختياري
Telegram اختياري
@
إذا ذكرت تيليغرام — سنرد عليك هناك أيضًا بالإضافة إلى البريد الإلكتروني.
WhatsApp اختياري
الصيغة: رمز الدولة + الرقم (مثال: +971XXXXXXXXX).

بالنقر على الزر، فإنك توافق على معالجة بياناتك.