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