فشل Db:seed_fu في 002_groups.rb أثناء الترقية: فشل التحقق من الصحة: الاسم موجود بالفعل

ساهم خلل
1

واجهت مشكلة أثناء الترقية من v2026.3.0-latest. يفشل مهمة rake db:seed_fu عند الوصول إلى الملف 002_groups.rb بالخطأ التالي:

ActiveRecord::RecordInvalid: Validation failed: Name has already been taken. (ActiveRecord::RecordInvalid)

تحدث الانهيار مباشرة عندما يحاول برنامج التهيئة (Seeder) تهيئة مجموعات النظام الجديدة (ID 4: anonymous و ID 5: logged_in_users).

تم التأكد من ذلك عبر وحدة تحكم Rails. فشل الفحص اليدوي في التحقق من صحة البيانات، لكن تجاوز التحقق يسمح لقاعدة البيانات بتسجيل السجل دون أي مشاكل:

# هذا يفشل برسالة "Name has already been taken"
g = Group.new(id: 4, name: "anonymous", automatic: true)
g.valid?

# هذا يعمل بشكل جيد، مما يثبت عدم وجود تضارب فعلي
g.save(validate: false)

تمكنت من تجاوز هذه العقبة بإنشاء مجموعات النظام الجديدة يدويًا:

ActiveRecord::Base.transaction do
  g4 = Group.new(id: 4, name: "anonymous", automatic: true)
  g4.save(validate: false)

  g5 = Group.new(id: 5, name: "logged_in_users", automatic: true)
  g5.save(validate: false)
end

الآن، عند تشغيل rake db:seed_fu، تكتمل المهمة دون أي أخطاء.

إعجابَين (2)
2

أين ذهب زر “أنا أيضًا!”؟

يحدث هذا عندما يكون لديك مجموعة أو مستخدم قائم باسم anonymous (!!!).

لدينا العديد من المنتديات التي استُخدم فيها اسم anonymous كاسم مستخدم بعد عملية الاستيراد.

يُشير الالتزام إلى:

يُقدم هذا الطلب (PR) مجموعتين تلقائيتين جديدتين: anonymous_users و logged_in_users

لكن يبدو أن المجموعة سُميت في النهاية anonymous بدون _users.

هذا أمر مؤسف لأن:

  • اسم anonymous يجعل من غير الواضح ما إذا كان مجموعة مستخدمين أو مستخدمًا فرديًا
  • يزداد خطر التصادم مع مجموعة أو مستخدم قائم بشكل كبير عند عدم وجود _users

الحلول المقترحة:
1 - تسمية المجموعة anonymous_users في النهاية، فهذا أكثر انسجامًا مع logged_in_users ويقلل خطر التصادم بشكل هائل
2 - على الأقل كشف التصادم وإعادة تسمية المستخدم أو المجموعة القائمة بدلاً من إظهار خطأ

إعجابَين (2)
5

سأقوم بالنظر في هذا.

هناك عملية هجرة للتعامل مع هذا التعارض في الأسماء، لذا لا أعرف لماذا لا تعمل في حالة صاحب المنشور الأصلي:

هل تقوم بتشغيل هذا بشكل منفصل قبل تشغيل عمليات الهجرة؟

6

تفحص عملية الترحيل الخاصة بك المجموعات الموجودة. ومع ذلك، يجب أن تفحص أيضًا المستخدمين الموجودين، لأن المستخدمين والمجموعات يشتركون في مساحة تسمية واحدة، ولا يمكن أن يكون هناك مجموعة تحمل نفس اسم مستخدم.

7

حسناً، هذا مزعج إلى حد ما… سأقوم الآن بإنشاء طلب سحب (PR) لتنفيذ ذلك:

وهو ما، كما تقول، سيقلل بشكل كبير من فرصة حدوث تصادم. أشك بشدة في وجود مستخدم يُدعى anonymous_users، لذا لا أعتقد أن هناك حاجة إلى فحص أو ترحيل آلي إذا قمت بهذا إعادة التسمية.

إعجاب واحد (1)
8

حسنًا، هذا يجب أن يفعل الحيلة، كما أنه يحل بعض المشكلات المتعلقة بمنطق التغييرات القادمة لـ Granular group-based permissions for anonymous and logged in users :

إعجابَين (2)
12

لا، ليس في البداية. كان الفشل يحدث أثناء عمليات الترحيل ضمن عملية إعادة البناء القياسية، وهو ما لفت انتباهي في البداية وقمت بتتبع السبب. بعد ذلك، كنت أشغّل مهمة Rake يدويًا لأغراض استكشاف الأخطاء وإصلاحها.

إعجابَين (2)
13

حسنًا، لقد دمجت طلب السحب الآن، ويجب أن يتولى حل تعارضات الأسماء.

إعجاب واحد (1)
14

هذه أخبار رائعة!

هل يمكنك أيضًا إعادة تطبيق التصحيح على الإصدار 2026.5؟

15

تم الإنجاز هنا DEV: Rename anonymous group to anonymous_users (#40435) by martin-brennan · Pull Request #40629 · discourse/discourse · GitHub

إعجاب واحد (1)