ماذا تود أن يتم؟
لدينا مكون مخصص للسمة (يُسمى “Bio Book”) بدأ مؤخرًا في إرجاع أخطاء 429. وقد بدأ ذلك في 26 نوفمبر. قبل ذلك كان يعمل بشكل طبيعي.
يقوم مكون “Bio Book” بتعديل مسار /u لعرض معلومات المستخدم بطريقة أكثر جمالية. ولتحقيق ذلك، كان أيضًا يطلب معلومات إضافية عن كل مستخدم من ملف .json الخاص به. وكان “Bio Book” يستخدم التحميل الكسول (lazy loading) لتجنب أخطاء 429، لكن هذا توقف عن العمل منذ أربعة أيام — ولا أعرف بالضبط ما الذي حدث قبل أربعة أيام، لكن فريق Discourse أكد أنه لم تُجرَ أي تغييرات على حدود المعدل (rate limit).
المطور الذي أنشأ المكون لنا في الأصل غير متاح لإجراء هذا الإصلاح، لذا نحتاج إلى شخص قادر على الدخول إلى الكود الحالي وحل الأخطاء حتى يعمل مكون السمة المخصص مرة أخرى.
لا نريد أي ميزات جديدة، ولا نحتاج إلى تغيير أي ميزات موجودة، ولا نريد إعادة هيكلة أي شيء. نريد فقط حل أخطاء 429 وإرجاع “Bio Book” إلى وظيفته السابقة.
متى تحتاج إلى أن يتم ذلك؟
نود إكماله بحلول يوم الاثنين، 6 يناير 2020.
ما هو ميزانيتك، بالدولار الأمريكي، التي يمكنك تقديمها لهذه المهمة؟
ميزانيتنا هي 250 دولارًا لحل أخطاء 429.
فهمنا هو أن حل أخطاء 429 سيحل جميع المشكلات الأساسية. وإذا لم يكن الأمر كذلك، يرجى إخبارنا وسنقوم بتعديل ميزانيتنا وفقًا لذلك.
إذًا، يتم التحميل الكسول في مجموعات من 50 مستخدمًا، كما أن القيمة الافتراضية لـ max_reqs_per_ip_per_10_seconds مضبوطة على 50 أيضًا. بما في ذلك الصفحة الرئيسية، سيقوم هذا الكود بإجراء ما لا يقل عن 51 طلبًا (في أقل من 10 ثوانٍ)، مما يتجاوز حد المعدل.
وبعبارة أخرى: لا أرى كيف يمكن أن يكون هذا قد عمل من قبل…؟
لقد قمنا بتفعيل حد المعدل عالميًا لجميع نسخ Discourse في جميع أنحاء العالم الأسبوع الماضي. يمكننا استكشاف الإضافة الأسبوع القادم لمعرفة ما إذا كانت هناك واجهة برمجة تطبيقات دفع معقولة يمكنها استخدامها بدلاً من ذلك.
واو، واجهتُ مؤخرًا نفس المشكلة لسبب مشابه جدًا (استدعاء معلومات المستخدم لعرض البطاقات!)، وطبقتُ حلاً مؤقتًا صغيرًا لإصلاحها، ثم جئتُ إلى المنتديات حرفيًا لأكتشف ما إذا كان هناك واجهة برمجة تطبيقات (API) دفعية لم أكن أعرفها… أو لأتعلم كيفية تنفيذ مثل هذا المسار.
لقد راجعتُ مكون السمة للتو. وهو بالفعل يُدخل قدرًا هائلاً من العمل وعددًا كبيرًا من المتطلبات. إن تحديد المعدل الذي قمنا به هنا صحيح تمامًا، حيث يعمل كنظام مناعي.
سنقوم بحل هذه المشكلة، لكن قد يستغرق ذلك أسبوعًا أو أسبوعين لإتمام جميع الأعمال.
يبدو لي أن الجزء الأكبر هنا هو أنك بحاجة إلى أن يبدأ دليل العناوين في إرجاع جميع المعلومات التي تحتوي عليها بطاقات المستخدمين. والمشكلة هي أن مكونات السمة لا تملك القدرة على تعديل الخادم، لذا سنحتاج إلى إجراء تغيير جوهري في واجهة برمجة التطبيقات (API) يسمح لنا بطلب بطاقات المستخدمين لعدة أشخاص دفعة واحدة.
سنقوم بتحديثك مع تقدمنا. وبخصوص الميزانية، سنقوم بهذه المهمة مجانًا، لكنني أقدّر أن العمل يستغرق حوالي يومين لإصلاح هذا الأمر، وهو ما يتجاوز بكثير الميزانية الأولية المخصصة هنا. يبدو الأمر بسيطًا في الظاهر، لكنه يتطلب تغييرات داخلية معقدة للغاية.
شكرًا لك يا @sam والفريق، هذا مفيد للغاية. إن التغييرات الأساسية في واجهة برمجة التطبيقات (API) ستخدمنا بلا شك، وأتخيل أنها ستفيد مستخدمي Discourse الآخرين. يسعدنا أن نتمكن من استخدام Bio Book وجعلها تعمل بطريقة أكثر منطقية. أسبوع أو أسبوعان يناسبنا.
أفهم ما تقصده بشأن الميزانية الأولية ونطاق الإصلاح. إنه لسخاء كبير منك أن تقوم بذلك مجانًا. شكرًا لك.
