تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها

ظهور تنسيقات مختلفة (و "صيغ" في بعض الأحيان) لبعض المشاكل في جدول المشاكل

قد تلاحظ تنسيقَين مختلفَين للمشاكل المدرَجة في جدول المشاكل في وحدة تحكّم Firebase. وقد تلاحظ أيضًا ميزة تُسمى "الصيغ" ضمن بعض مشاكلك. إليك السبب:

في أوائل عام 2023، طرحنا محرّك تحليل محسّنًا لتجميع الأحداث، بالإضافة إلى تصميم معدَّل وبعض الميزات المتقدّمة للمشاكل الجديدة (مثل الصيغ). يمكنك الاطّلاع على مشاركة المدوّنة الحديثة لمعرفة كل التفاصيل، أو يمكنك الاطّلاع أدناه على أهم النقاط.

يحلِّل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال والأعطال غير المميتة وأخطاء ANR) وينشئ مجموعات من الأحداث تُسمى المشاكل، وجميع الأحداث في مشكلة ما لها نقطة فشل مشتركة.

لتجميع الأحداث في هذه المشاكل، يفحص محرّك التحليل المحسَّن الآن العديد من جوانب الحدث، بما في ذلك اللقطات في تتبع تسلسل استدعاء الدوال البرمجية، ورسالة الاستثناء، ورمز الخطأ، وغيرها من سمات منصّة أو نوع الخطأ.

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

في ما يلي الميزات التي ستستفيد منها من خلال هذه التحسينات:

• البيانات الوصفية التي تمّ تجديدها والمعروضة ضمن صفّ المشكلة
  أصبح من الأسهل الآن فهم المشاكل في تطبيقك وتحديد أولوياتها.

• عدد أقل من المشاكل المكرّرة
  لا يؤدي تغيير رقم السطر إلى ظهور مشكلة جديدة.

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

• تنبيهات وإشارات أكثر وضوحًا
  تشير المشكلة الجديدة إلى خطأ جديد.

• بحث أكثر فعالية
  تحتوي كل مشكلة على المزيد من البيانات الوصفية القابلة للبحث، مثل نوع الاستثناء واسم الحزمة.

في ما يلي كيفية طرح هذه التحسينات:

• عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقق مما إذا كانت تتطابق مع مشكلة حالية.

• في حال عدم توفّر مطابقة، سنطبّق تلقائيًا خوارزمية تجميع الأحداث الذكية على الحدث وننشئ مشكلة جديدة باستخدام تصميم البيانات الوصفية المُعدَّل.

هذا هو التعديل الكبير الأول الذي نجريه على تجميع الأحداث. إذا كان لديك ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بها من خلال إرسال بلاغ.

عدم ظهور مقاييس عدم حدوث الأعطال و/أو تنبيهات السرعة

إذا لم تظهر لك المقاييس الخالية من الأعطال (مثل المستخدِمين والجلسات الخالية من الأعطال) و/أو تنبيهات السرعة، تأكَّد من استخدام الإصدار 18.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) من Crashlytics (أو الإصدار 32.6.0 أو إصدار أحدث من Firebase BoM).

عدم ظهور سجلّات شريط التنقل

إذا لم تظهر لك سجلّات مسار التنقّل، ننصحك بالتحقّق من إعدادات تطبيقك بشأن Google Analytics. يجب استيفاء المتطلبات التالية:

• لقد فعّلت Google Analytics في مشروعك على Firebase.

• فعّلت ميزة مشاركة البيانات لخدمة Google Analytics. اطّلِع على مزيد من المعلومات عن هذا الإعداد في مقالة إدارة إعدادات مشاركة البيانات في "إحصاءات Google".

• لقد أضفت حزمة تطوير البرامج (SDK) لمنصة Firebase لنظام التشغيل Google Analytics إلى تطبيقك. يجب إضافة حزمة تطوير البرامج هذه بالإضافة إلى حزمة تطوير البرامج Crashlytics.

• استخدام أحدث إصدارات حزمة تطوير البرامج (SDK) لمنصّة Firebase لجميع المنتجات التي تستخدمها في تطبيقك

  تأكّد بشكل خاص من استخدام على الأقل الإصدار التالي من حزمة تطوير البرامج (SDK) لبرنامج Google Analytics:
  Android: الإصدار 17.2.3 والإصدارات الأحدث (BoM الإصدار 24.7.1 والإصدارات الأحدث)

لماذا يتم الإبلاغ عن أخطاء ANR فقط في الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث؟

Crashlytics تتيح الإبلاغ عن أخطاء ANR في تطبيقات Android من الأجهزة التي تعمل بالإصدار Android 11 والإصدارات الأحدث. إنّ واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR (getHistoricalProcessExitReasons) هي أكثر موثوقية من الأساليب المستندة إلى SIGQUIT أو أدوات المراقبة. لا تتوفّر واجهة برمجة التطبيقات هذه إلا على أجهزة Android 11 والإصدارات الأحدث.

Why are some ANRs missing their BuildIds?

إذا كانت بعض أخطاء ANR لا تتضمّن BuildId، يمكنك تحديد المشاكل وحلّها على النحو التالي:

• تأكّد من استخدام أحدث إصدار من Crashlytics حزمة تطوير البرامج (SDK) لنظام التشغيل Android و Crashlytics المكوّن الإضافي لنظام Gradle.

  إذا لم تتوفّر BuildId لنظام التشغيل Android 11 وبعض أخطاء ANR في Android 12، من المحتمل أنّك تستخدم حزمة تطوير برامج (SDK) أو مكوّن إضافي لنظام Gradle أو كليهما قديماً. لجمع BuildId بشكل صحيح لهذه الأخطاء ANR، عليك استخدام الإصدارين التاليين من IDE:

  • Crashlytics الإصدار 18.3.5 من حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإصدارات الأحدث (الإصدار 31.2.2 من Firebase BoM والإصدارات الأحدث)
  • Crashlytics الإصدار 2.9.4 من المكوّن الإضافي Gradle والإصدارات الأحدث

• تحقّق ممّا إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.

  إذا لم تكن لديك سوى BuildIds للمكتبات المشتركة في تطبيقك، من المحتمل أنّك لا تستخدم الموقع التلقائي العادي للمكتبات المشتركة. في هذه الحالة، قد لا يتمكّن Crashlytics من تحديد مكان BuildId المرتبطة. ننصحك باستخدام الإعداد التلقائي للوقو الجديد للمكتبات المشتركة.

• تأكَّد من عدم إزالة BuildId أثناء عملية الإنشاء.

  يُرجى العلم أنّ النصائح التالية لتحديد المشاكل وحلّها تنطبق على كلّ من أخطاء ANR والأعطال المبرمَجة.

  • تحقَّق من توفّر BuildId من خلال تشغيل readelf -n على الملفات الثنائية. إذا كانت BuildId غير متوفّرة، أضِف -Wl,--build-id إلى العلامات الخاصة بنظام الإنشاء.

  • تأكَّد من أنّك لا تزيل BuildId عن غير قصد في محاولة لتقليل حجم حزمة APK.

  • إذا احتفظت بنسخ من مكتبة تمّت إزالة المحتوى غير الضروري منها وغير ذلك، احرص على الإشارة إلى النسخة الصحيحة في الرمز البرمجي.

الاختلافات بين تقارير أخطاء ANR في لوحة بيانات Crashlytics وGoogle Play Console

قد يكون هناك تعارض بين عدد أخطاء ANR بين Google Play وCrashlytics. وهذا أمر متوقّع بسبب الاختلاف في آلية جمع بيانات ANR والإبلاغ عنها. يُبلغ Crashlytics عن أخطاء ANR عند بدء تشغيل التطبيق next، في حين تُرسِل "مؤشرات Android الحيوية" بيانات أخطاء ANR بعد حدوثها.

بالإضافة إلى ذلك، لا يعرض Crashlytics سوى أخطاء ANR التي تحدث على الأجهزة التي تعمل بالإصدار 11 من Android والإصدارات الأحدث، مقارنةً بـ Google Play الذي يعرض أخطاء ANR من الأجهزة التي تم قبول موافقة جمع البيانات عليها وتمت إتاحة "خدمات Google Play" عليها.

الاختلافات بين عمليات تتبُّع تسلسل استدعاء الدوال البرمجية في NDK في لوحة بيانات Crashlytics وlogcat

تتضمّن سلاسل أدوات LLVM وGNU إعدادات تلقائية ومعالجات مختلفة للجزء المخصّص للقراءة فقط من الملفات الثنائية لتطبيقك، ما قد يؤدي إلى إنشاء عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير متّسقة في وحدة تحكّم Firebase. للحدّ من ذلك، أضِف علامات الربط التالية إلى عملية الإنشاء:

• إذا كنت تستخدم أداة الربط lld من سلسلة أدوات LLVM، أضِف ما يلي:

  -Wl,--no-rosegment

• إذا كنت تستخدم أداة الربط ld.gold من مجموعة أدوات GNU، أضِف ما يلي:

  -Wl,--rosegment

إذا كنت لا تزال ترى عدم اتساق في تتبع تسلسل استدعاء الدوال البرمجية (أو إذا لم يكن أي من العلامتَين متعلقًا بمجموعة أدوات التطوير)، جرِّب إضافة ما يلي إلى عملية الإنشاء بدلاً من ذلك:

-fno-omit-frame-pointer

كيف يمكنني استخدام ملف الترميز الثنائي الخاص بي لإنشاء ملف الترميز في Breakpad لـ NDK؟

يُجمِّع المكوِّن الإضافي Crashlytics أداة إنشاء مخصّصة لملفات رموز Breakpad. إذا كنت تفضّل استخدام ملف ثنائي خاص بك لإنشاء ملفات رموز Breakpad (مثلاً، إذا كنت تفضّل إنشاء جميع الملفات التنفيذية الأصلية في سلسلة الإنشاء من المصدر)، استخدِم سمة الإضافة symbolGeneratorBinary الاختيارية لتحديد مسار الملف التنفيذي.

يمكنك تحديد المسار إلى الملف الثنائي لبرنامج إنشاء ملفات الرموز البرمجية Breakpad بإحدى الطريقتَين التاليتَين:

• الخيار 1: تحديد المسار من خلال إضافة امتداد firebaseCrashlytics في ملف build.gradle

  أضِف ما يلي إلى ملف build.gradle.kts على مستوى التطبيق:

  الإصدار 3.0.0 من المكوّن الإضافي لنظام Gradle والإصدارات الأحدث

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  إصدارات المكوّنات الإضافية الأقل

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• الخيار 2: تحديد المسار من خلال سطر سمة في ملف Gradle properties

  يمكنك استخدام السمة com.google.firebase.crashlytics.breakpadBinary لتحديد مسار الملف التنفيذي.

  يمكنك تعديل ملف خصائص Gradle يدويًا أو تعديل الملف من خلال سطر الأوامر. على سبيل المثال، لتحديد المسار من خلال سطر الأوامر، استخدِم أمرًا مثل ما يلي:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

عدم حدوث أعطال عند استخدام Dexguard

إذا ظهر لك الاستثناء التالي، من المحتمل أنّك تستخدم إصدارًا من DexGuard غير متوافق مع حزمة SDK الخاصة بتطبيق Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

لا يؤدي هذا الاستثناء إلى تعطُّل تطبيقك، ولكنه يمنعه من إرسال تقارير تتعلّق بالانهيار. لحلّ هذه المشكلة، اتّبِع الخطوات التالية:

1. تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يتضمّن أحدث إصدار قواعد مطلوبة من حزمة تطوير البرامج (SDK) لتطبيق Firebase Crashlytics.

2. إذا كنت لا تريد تغيير إصدار DexGuard، جرِّب إضافة السطر التالي إلى قواعد التشويش (في ملف إعدادات DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

لماذا أرى أعطالًا من .kt ملفًا مصنّفًا على أنّه يتضمن مشاكل .java؟

عندما يستخدم التطبيق أداة تشويش لا تُظهر امتداد الملف، Crashlytics ينشئ كل مشكلة باستخدام امتداد ملف .java تلقائيًا.

لكي تتمكّن أداة Crashlytics من إنشاء مشاكل باستخدام إضافة الملف الصحيحة، تأكّد من أنّ تطبيقك يستخدم الإعدادات التالية:

• استخدام الإصدار 4.2.0 من Android Gradle أو إصدار أحدث
• يستخدم R8 مع تفعيل التشويش. لتحديث تطبيقك إلى الإصدار R8، اتّبِع خطوات المستندات هذه.

يُرجى العلم أنّه بعد التحديث إلى الإعداد الموضّح أعلاه، قد تبدأ في رؤية مشاكل .kt جديدة هي نُسخ طبق الأصل من مشاكل .java الحالية. يمكنك الاطّلاع على الأسئلة الشائعة لمعرفة المزيد من المعلومات حول هذه الحالة.

لماذا أرى .kt مشكلة مكرّرة لحالة .java حالية؟

اعتبارًا من منتصف كانون الأول (ديسمبر) 2021، Crashlytics تحسين التوافق مع التطبيقات التي تستخدم لغة Kotlin

حتى وقت قريب، لم تُظهِر برامج التشويش المتاحة امتداد الملف، لذا كانت Crashlytics تنشئ كل مشكلة باستخدام امتداد ملف .java تلقائيًا. ومع ذلك، اعتبارًا من الإصدار 4.2.0 من "نظام Gradle المتوافق مع Android"، يتيح R8 استخدام إضافات الملفات.

من خلال هذا التعديل، يمكن الآن لـ Crashlytics تحديد ما إذا كانت كل فئة مستخدَمة في التطبيق مكتوبة بلغة Kotlin وتضمين اسم الملف الصحيح في ملف التوقيع الخاص بالمشكلة. يتم الآن تحديد مصدر الأعطال بشكل صحيح على أنّه ملفات .kt (حسب الاقتضاء) إذا كان تطبيقك يتضمّن الإعدادات التالية:

• يستخدم تطبيقك الإصدار 4.2.0 من Android Gradle أو إصدارًا أحدث.
• يستخدم تطبيقك R8 مع تفعيل التشويش.

بما أنّ الأعطال الجديدة تتضمّن الآن امتداد الملف الصحيح في ملف التوقيع الخاص بها، قد تظهر لك مشاكل .kt جديدة هي في الواقع مجرد نُسخ طبق الأصل من المشاكل الحالية المصنّفة على أنّها .java. في وحدة تحكّم Firebase، نحاول تحديد وإبلاغك إذا كانت مشكلة .kt جديدة هي نسخة محتملة من مشكلة حالية مصنّفة على أنّها .java.

مَن يمكنه عرض الملاحظات حول مشكلة معيّنة وكتابتها وحذفها؟

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو إرسال رسائل بشأن الحالة أو غيرها.

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

يوضِّح ما يلي الأذونات المطلوبة لعرض الملاحظات وكتابتها وحذفها:

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة.

  • مالك المشروع أو محرّره، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات المنشورة بشأن مشكلة معيّنة، ولكن لا يمكنهم حذف ملاحظة أو كتابتها.

  • مُشاهد المشروع، مُشاهد Firebase، مُشاهد الجودة، أو مُشاهد Crashlytics

كيف يتم احتساب عدد المستخدمين الذين لم يواجههم أي تعطُّل؟

اطّلِع على فهم المقاييس الخالية من الأعطال.

مَن يمكنه عرض الملاحظات حول مشكلة معيّنة وكتابتها وحذفها؟

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو إرسال رسائل بشأن الحالة أو غيرها.

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

يوضِّح ما يلي الأذونات المطلوبة لعرض الملاحظات وكتابتها وحذفها:

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة حول مشكلة.

  • مالك المشروع أو محرّره، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات المنشورة بشأن مشكلة، ولكن لا يمكنهم حذف ملاحظة أو كتابتها.

  • مُشاهد المشروع، مُشاهد Firebase، مُشاهد الجودة، أو مُشاهد Crashlytics

يستخدم التطبيق أيضًا حزمة SDK الخاصة بمنصّة Google Mobile Ads، ولكنّه لا يتضمّن أي أعطال.

إذا كان مشروعك يستخدم Crashlytics إلى جانب حزمة SDK Google Mobile Ads، من المحتمل أن يتداخل أدوات تسجيل الأعطال عند تسجيل معالجات الاستثناءات. لحلّ المشكلة، أوقِف ميزة الإبلاغ عن الأعطال في حزمة SDK الخاصة بمنصّة Mobile Ads من خلال الاتصال برقم disableSDKCrashReporting.

أين تقع مجموعة بياناتي على BigQuery؟

بعد ربط Crashlytics بخدمة BigQuery، يتم تحديد موقع مجموعات البيانات الجديدة التي تنشئها تلقائيًا في الولايات المتحدة، بغض النظر عن موقع مشروعك على Firebase.

هل يتوافق Crashlytics مع armeabi؟

لا يتوافق NDK لنظام التشغيل Firebase Crashlytics مع ARMv5 (armeabi). تم إيقاف واجهة برمجة التطبيقات هذه اعتبارًا من الإصدار r17 من NDK.

ما هي المشكلة التي تم حلّها؟

حدثت إعادة انحدار في مشكلة سبق أن تم إغلاقها، ولكن Crashlytics تلقّى تقريرًا جديدًا يفيد بإعادة حدوث المشكلة. يعيد Crashlytics فتح هذه المشاكل التي تراجعت مؤشراتها تلقائيًا حتى تتمكّن من حلّها بما يناسب تطبيقك.

في ما يلي مثال على سيناريو يوضّح كيف يصنف Crashlytics مشكلة على أنّها انحدار:

1. للمرة الأولى على الإطلاق، يتلقّى Crashlytics تقرير عطل بشأن العُطل "أ". يؤدي النقر على Crashlytics إلى فتح مشكلة مقابلة لهذا العُطل (المشكلة "أ").
2. يمكنك إصلاح هذا الخطأ بسرعة وإغلاق المشكلة "أ"، ثم إصدار إصدار جديد من تطبيقك.
3. تلقّى "Crashlytics" تقريرًا آخر بشأن المشكلة "أ" بعد إغلاق المشكلة.
   • إذا كان التقرير واردًا من إصدار تطبيق كان فريق Crashlytics على دراية به عند إغلاق المشكلة (أي أنّ الإصدار أرسل تقرير تعطُّل لأي تعطُّل على الإطلاق)، لن يعتبر فريق Crashlytics أنّ المشكلة قد عادت للظهور. ستظلّ المشكلة مغلقة.
   • إذا كان التقرير واردًا من إصدار تطبيق لم يكن Crashlytics على عِلم به عند إغلاق المشكلة (أي أنّ الإصدار لم يرسل أي تقرير عن أي عطل على الإطلاق)، سيعدّ Crashlytics أنّ المشكلة قد عادت للظهور وسيعيد فتح التقرير.

عندما تتدهور مشكلة، نرسل تنبيهًا برصد الانحدار ونضيف إشارة انحدار إلى المشكلة لإعلامك بأنّ Crashlytics قد أعاد فتح المشكلة. إذا كنت لا تريد إعادة فتح مشكلة بسبب اتّباعنا لخوارزمية التراجُع، يمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.

لماذا تظهر لي مشاكل تتعلّق بالأداء المنخفض في الإصدارات القديمة من التطبيق؟

إذا كان التقرير واردًا من إصدار قديم من التطبيق لم يرسل أي تقارير أعطال على الإطلاق عند إغلاق المشكلة، سيعتبر فريق Crashlytics أنّ المشكلة قد عادت للظهور مجددًا وسيعيد فتحها.

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

إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية الانحدار، يمكنك "كتم صوت" المشكلة بدلاً من إغلاقها.