نعم، أعتقد أن هذه هي المشكلة. يُرجّح نموذج اللغة الكبير أن الكود لا يتعامل جيدًا مع قائمة من الإدخالات، مما يؤدي إلى خطأ 500.
حسنًا، هل يبدو أننا في نطاق #contribute:bug؟
أعتقد أن هذا خلل برمجي، وأتوقع أن تكون الإصلاحات بسيطة، لكنني لا أفهم الفئات الجديدة حقًا. (وشخصيًا، لن أقدم أي كود إذا لم أشعر أنني أفهمه بالكامل.)
هناك أيضًا مسألة ما إذا كانت حالة قاعدة بياناتك ناتجة عن خلل برمجي آخر يحتاج هو الآخر إلى إصلاح.
وبما أن هذا الموضوع لم يساهم فيه سوى ثلاثة أشخاص، فقد يكون من المفيد إنشاء موضوع جديد للإبلاغ عن الخلل - وإذا رغب أحد المشرفين في دمج الموضوعات أو إعادة تصنيفها، فيمكنهم دائمًا القيام بذلك.
حسنًا، لم أكن في الواقع قد رأيت موضوع Contribute > Bug من قبل، ولا أذكر أنني نشرت فيه قط، كما أنني لا أملك المستوى المهاري اللازم لتحديد ما إذا كان الأمر خللًا برمجيًا أم لا.
بالإضافة إلى ذلك، نعم، على الأرجح أنت على صواب، فقد تكون هناك بعض المشكلات التاريخية في قاعدة البيانات هي التي أدت إلى هذا النقطة الحساسة.
وعلى الرغم من أن هناك حاجة ملحة لجعل حساب المسؤول قابلًا للوصول مرة أخرى، في أقرب وقت ممكن، إلا أنني أعتقد أن ذلك يعتمد على الظروف، لكن على الأقل ربما نكون قد وصلنا إلى مصدر المشكلة، لذا آمل أن يكون كل شيء على ما يرام!
شكرًا لمساعدتك. 
أيضًا، أتساءل إن كان هذا يمنح بعض المصداقية لفكرة إلغاء وضع المدير من حساب المستخدم، وتغييره إلى مستوى حساب مشرف على سبيل المثال، وقد يتجاوز هذا المشكلة عند تسجيل الدخول.
ربما سأجرّب ذلك بعد أخذ نسخة احتياطية من البيانات.
مخاوفي تكمن في فقدان البيانات أو كسر أشياء لن أعرف كيف أتحقق منها، إذا بدا كل شيء على ما يرام ولم تظهر أي أخطاء. 
العفو. لقد كان الأمر مثيرًا للاهتمام.
ربما توجد طريقة بسيطة يمكنك من خلالها استخدام SQL لإزالة ذلك السجل المكرر، لكنني شخصيًا لن أقوم بذلك باستخفاف.
كما أنه من الممكن، وفقًا لنموذج اللغة، استخدام وحدة تحكم Rails لتحديث دالة Ruby المكونة من عشرة أسطر وتعزيز حمايتها. على الأقل، يجب أن يكون ذلك أمرًا آمنًا، لأن إعادة التشغيل ستعيد تحميل كود Ruby الفعلي من القرص.
أريد لصق هذا النص لحفظه حتى أتمكن من إغلاق التبويب - كود غير مُختبَر من نموذج اللغة الكبير (LLM)، يُقدَّم هنا كإصلاح مؤقت (monkey patch) لتطبيقه في وحدة تحكم Rails على نظام قيد التشغيل، كما يحتوي على إصلاح مقترح من نموذج اللغة الكبير لهذا الهشاشة التي تسببت في الخطأ:
# إعادة فتح CurrentUserSerializer لتجاوز الطريقة المعطلة
class CurrentUserSerializer < ApplicationSerializer
def has_new_upcoming_changes
last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
# استخراج السلسلة إذا كانت مخزنة كمصفوفة بواسطة المُحمِّل المسبق
last_visited = last_visited.first if last_visited.is_a?(Array)
return false if last_visited.blank? && object.created_at < Discourse.site_creation_date + 1.hour
cutoff = last_visited.present? ? Time.zone.parse(last_visited.to_s) : object.created_at
UpcomingChangeEvent.added.not_backfilled.where("created_at > ?", cutoff).exists?
end
end
سحب الصلاحيات الإدارية
تُطبَّق الإجراءات على حساب المستخدم الإداري الأصلي المحجوب:
-
سحب الصلاحيات الإدارية + منح صلاحيات المشرف = فشل تسجيل الدخول/نفس الخطأ.
-
سحب صلاحيات المشرف
- تسجيل الدخول الأول (بدون خطأ) لكن يتوقف عند مرحلة التحقق الثنائي/دائرة تحميل تسجيل الدخول
- تركته لمدة 10 دقائق تقريبًا (كان الخادم يُظهر زيادة في الحمل عند تسجيل الدخول)، ولم يحدث شيء
- ومع ذلك، يُظهر تبويب “المستخدمين النشطين” أن المستخدم سجّل الدخول قبل X دقيقة، هاه
- محاولة تسجيل الدخول الثاني في نافذة أخرى (خاصة) تنجح!
حسنًا، يبدو أن هذا يمثل حلًا بديلًا لمستخدم إداري قد يحتاج إلى قراءة الرسائل/الدردشات وما إلى ذلك، لكنه لا يحل المشكلة في النهاية.
التالي، باستخدام حساب إداري آخر، منح صلاحيات إدارية لحساب المستخدم الإداري السابق المسجّل دخولًا
- أثناء تسجيل الدخول، يصل إشعار تحديث إداري يشير إلى النجاح.
- تحديث الصفحة ويظهر خطأ مرة أخرى
لا أستطيع النشر في موضوع “Git hang” لأنه أُغلق اعتباراً من 28 سبتمبر، لكن عندما لاحظت بعض البطء قبل بضع دقائق، فكرت: أوه، ربما توقف git مرة أخرى ويسبب مشاكل، وصدقاً، كان موقع downdetector.com يعرض ارتفاعاً كبيراً في انقطاع الخدمة على GitHub في ذلك الوقت تقريباً.