كيفية إصلاح DELETE_FAILED في عمليات نشر Salesforce

يُحظر حذف سجل بسبب علاقة بحث (lookup) أو مشغّل (trigger) أو موافقة معلّقة، بمعزل عن خطأ DEPENDENCY_EXISTS على مستوى البيانات الوصفية.

يظهر أثناء: عمليات حذف DML وقت التشغيل، في تحميل البيانات ومهام الدفعات واختبارات Apex

المعنى

DELETE_FAILED خطأ على مستوى البيانات يظهر عندما لا يمكن إتمام عملية حذف DML، غالبًا لأن سجلًا آخر لا يزال يحمل مرجع بحث (lookup) أو علاقة رئيسي-تفصيلي (master-detail) إليه، أو لأن مشغّلًا اعترض على الحذف، أو لأن السجل مقفل بموافقة معلّقة. ينطبق هذا على حذف السجلات أثناء تحميل البيانات واختبارات Apex، وليس على حذف مكونات البيانات الوصفية.

تُحذف السجلات التابعة في علاقة رئيسي-تفصيلي تلقائيًا عند حذف السجل الرئيسي، لذا يتعلق هذا الخطأ غالبًا بعلاقة بحث، حيث يترك Salesforce خيار التتابع (cascade) أو الحظر لتكوين الحقل، أو بمنطق مخصص يمنع الحذف صراحةً.

التشخيص

الأسباب الشائعة

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

الحل

  1. احذف السجلات التابعة أو أعد ربطها أولًا
    أزل أو حدّث حقل البحث على السجلات التابعة قبل حذف السجل الرئيسي، أو غيّر إعداد الحقل ليُمسح عند الحذف إذا كان ذلك هو السلوك الصحيح.
  2. راجع منطق المشغّلات وقواعد التحقق
    ابحث عن منطق يحظر الحذف في مشغّلات Apex (trigger.isDelete) وقواعد التحقق التي تُفعَّل عند الحذف.
  3. ألغِ الموافقات المعلّقة أو أكملها
    أنهِ أي عملية موافقة جارية على السجل قبل محاولة حذفه.
من واقع الاستخدام

إزاي Serpent بتمنع ده

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

أداة بناء pipelines لـ CI/CD بلا كود في Serpent

الوقاية

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

DELETE_FAILED، بالشرح

هل DELETE_FAILED هو نفسه خطأ DEPENDENCY_EXISTS؟
لا. يحظر DEPENDENCY_EXISTS حذف بيانات وصفية، مثل حقل أو كائن، لأن بيانات وصفية أخرى تشير إليها. بينما يحظر DELETE_FAILED حذف سجل بيانات لأن سجلات أخرى أو أتمتة تشير إليه.
لماذا ينجح حذف السجل الرئيسي أحيانًا ولا ينجح أحيانًا أخرى مع حقل البحث نفسه؟
سلوك الحذف لحقل البحث يُضبط لكل حقل على حدة، وليس تلقائيًا. إذا كان مضبوطًا على مسح القيمة عند الحذف، يُحذف السجل الرئيسي دون مشكلة؛ وإذا كان مضبوطًا على تقييد الحذف، فإن أي مرجع تابع يحظره.
هل يُعد نقل السجل إلى سلة المهملات بمثابة حذف لهذا الفحص؟
نعم، الحذف الناعم (soft delete) إلى سلة المهملات لا يزال يُفعّل فحوصات التبعية والمشغّلات نفسها كما في الحذف النهائي؛ لا يختفي السجل فعليًا حتى تُفرغ السلة، لكن فحص DELETE_FAILED يُنفَّذ عند خطوة الحذف الناعم.

ابدأ مجانًا. دون بطاقة ائتمان، دون تثبيت، ودون التزام.

الإعداد في أقل من 15 دقيقة. لا حاجة لتوظيف مختص DevOps.

هل تريد معرفة كيف يمكنكم الشحن أسرع قبل البدء؟ لنتحدث

بدون التزام.