ما الذي قد يحتويه تقرير تعطل تطبيق اليوميات؟
يمكن أن يتضمن تقرير تعطل تطبيق اليوميات تفاصيل تقنية مثل تتبع مكدس التعطل (crash stack trace)، وإصدارات الجهاز والتطبيق، والطوابع الزمنية، وأحداث التشخيص المجاورة. وتِبعاً لنظام التشغيل، وخدمة إعداد التقارير، وتكوين التطبيق، قد يتضمن أيضاً سجلات أو مرفقات أو بيانات إعادة تشغيل الجلسة التي تكشف عن المحتوى المُدخل أو المعروض في التطبيق. لا يحتوي التقرير تلقائياً على تدوينات اليوميات في كل الحالات، كما أنه ليس من الآمن افتراض أنه لا يحتوي عليها أبداً. تحقق من التقرير المحدد وكيفية تكوين التطبيق قبل مشاركته.
ما الذي يُظهره تقرير التعطل القياسي؟
يسرد تتبع المكدس (stack trace) استدعاءات الدوال المرتبطة بالتعطل. فهو يساعد المطورين على تحديد مسار التعليمات البرمجية المعنية، ولكنه عادةً لا يوضح بمفرده الظروف الكاملة أو يثبت ما كان يفعله المستخدم. قد تحدد التقارير أيضاً إصدارات التطبيق ونظام التشغيل، وطراز الجهاز، ووقت التعطل، وتفاصيل البيئة الأخرى. تصف شركة Apple تقارير التعطل بأنها سجلات لحالة التطبيق في وقت التعطل وتوصي بتحليل تقرير نظام التشغيل الكامل؛ وتحدد إرشاداتها حقولاً مثل معلومات الجهاز والتطبيق ونظام التشغيل. راجع [دليل تحليل تقارير التعطل](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report) من Apple.
يعتمد تنسيق التقرير على مصدره. فتُعد تقارير تعطل Apple المجمعة عبر Xcode وتقرير أخطاء Android ملفين مختلفين. يذكر دليل Android الرسمي أن تقرير الأخطاء يمكن أن يحتوي على سجلات الجهاز، وتتبعات المكدس، ومخرجات التشخيص من خدمات النظام، وسجلات الأخطاء، ورسائل النظام من التطبيقات التي تستخدم فئة `Log` في Android. وهذا أوسع نطاقاً من مجرد سجل مقتصر على التعطل. وتظل محتويات التقرير الفردي معتمدة على ما تم جمعه وتضمينه. راجع [دليل Android لتسجيل وقراءة تقارير الأخطاء](https://developer.android.com/studio/debug/bug-report).
هل يمكن أن يتضمن التقرير نص اليوميات؟
يمكنه ذلك، في ظل بعض التكوينات، ولكن مجرد وجود تقرير تعطل لا يثبت أنه يتضمن نص التدوينة. السؤال الأساسي هو ما يسجله التطبيق إلى جانب التعطل وما يلتقطه تنسيق التقرير.
على سبيل المثال، قد يضيف مطورو التطبيقات رسائل سجل تشخيصية أو أحداثاً مخصصة. إذا كانت تلك الرسائل تتضمن تدوينة يوميات، أو عنواناً، أو مصطلح بحث، أو نصاً تم نسخه من محرر، فقد تنتقل هذه المعلومات مع الحدث. تصف Sentry مسارات التنقل (breadcrumbs) بأنها أثر للأحداث التي سبقت المشكلة؛ ويمكن أن يحتوي كل منها على رسالة وبيانات مهيكلة عشوائية. قد يتم جمع مسارات التنقل تلقائياً من خلال عمليات الدمج المُمكّنة أو إضافتها بواسطة التطبيق. راجع [وثائق مسارات التنقل (breadcrumbs) الخاصة بـ Sentry](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). تتضمن تقارير أخطاء Android أيضاً سجلات رسائل النظام، والتي قد تحتوي على رسائل مكتوبة بواسطة التطبيقات. ولا تعني أي من هاتين الحقيقتين أن كل تطبيق يسجل نصوصاً خاصة: فهذا يعتمد على تنفيذ التطبيق وتكوينه.
ما هي السجلات، ومسارات التنقل، والمرفقات، وإعادة التشغيل؟
تشير هذه المصطلحات إلى أنواع متميزة من بيانات التشخيص. السجلات (Logs) هي رسائل يسجلها التطبيق أو النظام. ومسارات التنقل (Breadcrumbs) هي تسلسل محدد من الأحداث التي أدت إلى حدوث خطأ، وقد تشمل طوابع زمنية وفئات ورسائل وبيانات مفتاح-قيمة. ويمكن لكلاهما الكشف عن سياق أكثر مما يكشفه تتبع المكدس، اعتماداً على ما يسجله التطبيق.
المرفقات (Attachments) هي ملفات تُرسل مع الحدث، مثل ملف سجل، أو لقطة شاشة، أو ملف تفريغ الذاكرة عند التعطل (crash dump). تشير Sentry إلى أن ملفات التفريغ المصغر الأصلية (native minidumps) يمكن أن تحتوي على مواد حساسة مثل متغيرات البيئة، أو المسارات المحلية، أو تمثيلات حقول الإدخال في الذاكرة. وتذكر وثائقها أن ملفات التفريغ المصغر تُستخدم لإنشاء الأحداث ويتم التخلص منها افتراضياً، ولكن يمكن تخزينها كمرفقات إذا تم تمكين هذا الإعداد؛ وتذكر أيضاً أن المرفقات لا يشملها نظام تنقية البيانات (data scrubbing) في Sentry. راجع [وثائق Sentry حول بيانات التعطل](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) و[المرفقات](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
إعادة تشغيل الجلسة (Session replay) هي ميزة اختيارية منفصلة، وليست مكوناً قياسياً في كل تقرير تعطل. تصف وثائق إعادة التشغيل الخاصة بـ JavaScript في Sentry إعادة بناء تشبه الفيديو لنشاط المتصفح، بما في ذلك حالة نموذج كائن المستند (DOM) والتفاعلات. وتذكر أن حزمة أدوات تطوير البرمجيات (SDK) تحجب نصوص DOM والصور ومدخلات المستخدم افتراضياً، مع توفير خيارات للتكوين أيضاً. وتعد إعدادات الحجب والمنصات المدعومة أمراً مهماً: فلا تستنتج أن محتوى اليوميات إما مرئي أو محمي دون التحقق من إعداد المزود الفعلي وتكوين الخصوصية. راجع [دليل إعادة تشغيل الجلسة لـ JavaScript من Sentry](https://docs.sentry.io/platforms/javascript/session-replay/).
ما الذي يجب عليك مراجعته قبل مشاركة التقرير؟
استخدم قائمة التحقق هذه على الملف الفعلي أو معاينة التقرير، وتحقق من وثائق خصوصية التطبيق أو المزود عندما تكون محتويات التقرير غير واضحة:
قائمة التحقق هذه هي إرشادات تحريرية عملية لمستخدم اليوميات لمراجعة التقرير قبل إرساله. وهي منفصلة عن تعليمات المصنّع: يتحكم المطورون في إعدادات التسجيل وإعادة التشغيل والمرفقات الخاصة بهم، ويجب عليهم توثيق ما تجمعه تلك الميزات ومراجعة ما إذا كانت حقول التشخيص يمكن أن تحتوي على محتوى أدخله المستخدم.
لماذا قد تختلف التقارير بين التطبيقات والأجهزة؟
تُنتج أنظمة التشغيل تنسيقات تقارير ومسارات جمع مختلفة؛ وقد يستخدم المطورون أيضاً حزمة تطوير برمجيات (SDK) تابعة لجهات خارجية بتكوين مخصص. تذكر Apple أن تقارير تعطل App Store وTestFlight متاحة من خلال Xcode، بينما قد يلزم نقل سجلات التشخيص الأخرى من الجهاز. ويميز Android بين تقارير الأخطاء الكاملة وتقارير التعطل المقدمة من خلال خدمات مثل Google Play أو Firebase. ويمكن لإعدادات المزود أن تحدد أيضاً الأحداث، أو مسارات التنقل، أو المرفقات، أو بيانات إعادة التشغيل التي يتم التقاطها وتخزينها. تعامل مع إشعار خصوصية التطبيق والتقرير الفعلي كدليل للحالة المعينة، بدلاً من افتراض أن كل خدمة ترسل نفس الحقول.