Comment corriger ENTITY_IS_DELETED dans les déploiements Salesforce

Les métadonnées ou l'enregistrement que le déploiement référence ont été supprimés, ou se trouvent dans la Recycle Bin, dans l'org cible.

Se produit lors de : DML à l'exécution et déploiements de métadonnées référençant un composant depuis supprimé

Ce que cela signifie

ENTITY_IS_DELETED signifie que le composant ou l'enregistrement que votre déploiement s'attend à trouver a déjà été supprimé dans l'org cible. Cela se produit lorsque des métadonnées récupérées précédemment sont désormais obsolètes, ou lorsqu'un changement destructif et un déploiement dépendant s'exécutent dans le mauvais ordre l'un par rapport à l'autre.

Cela peut se déclencher à l'un ou l'autre niveau : une requête Apex ou une instruction DML qui touche un enregistrement supprimé de façon réversible et toujours dans la Recycle Bin, ou un déploiement via la Metadata API référençant un composant qu'un précédent destructiveChanges.xml a déjà retiré de l'org cible.

Diagnostic

Causes courantes

Métadonnées locales obsolètes

Un champ, un objet ou un record type a été supprimé directement dans l'org cible après le dernier retrieve, si bien que les métadonnées locales y font toujours référence.

Données de test supprimées en cours de transaction

Un test Apex ou un trigger supprime un enregistrement qu'une étape ultérieure de la même transaction tente d'interroger ou de mettre à jour.

Changements destructifs exécutés dans le mauvais ordre

Une suppression via destructiveChanges.xml s'exécute avant des métadonnées qui dépendent encore du composant en cours de suppression.

La solution

Resynchronisez avant de déployer
Récupérez les métadonnées actuelles depuis l'org cible pour confirmer que le composant existe vraiment encore là-bas.
```
sf project retrieve start --target-org myOrgAlias --metadata CustomField:Account.Legacy_Score__c
```
Supprimez ou restaurez la référence
Supprimez la référence obsolète de vos métadonnées, ou restaurez le composant depuis la Recycle Bin s'il devrait encore exister.
Séquencez correctement les changements destructifs
Déployez d'abord les changements de métadonnées dépendants, puis exécutez ensuite les suppressions destructives, en suivant le modèle de déploiement destructif en deux étapes de Salesforce.

En pratique

Comment Serpent évite cela

Serpent AI récupère l'état de l'org en direct avant chaque tâche et signale un composant supprimé comme un conflit de diff à résoudre, plutôt que de le laisser échouer en plein déploiement. Voir la bibliothèque des erreurs de déploiement Salesforce.

Métadonnées et données dans un seul flux de déploiement dans Serpent

Prévention

Faites un retrieve avant chaque workflow retrieve-and-modify, ne présumez jamais de la fraîcheur

Traitez les métadonnées mises en cache localement comme jetables ; récupérez un état frais depuis l'org cible juste avant de construire un déploiement contre celle-ci.

Ré-interrogez les enregistrements après toute suppression au sein de la même transaction

Ne présumez jamais qu'un enregistrement interrogé plus tôt dans une méthode Apex existe encore après qu'une instruction delete s'exécute plus tard dans la même transaction ; ré-interrogez ou restructurez la logique.

Standardisez sur destructiveChangesPre/Post.xml pour chaque suppression

Divisez toujours les suppressions à l'aide des fichiers de changement destructif pre et post documentés par Salesforce plutôt que d'un ordonnancement de suppression ad hoc.

Erreurs associées

DEPENDENCY_EXISTSLe blocage qui empêche cette erreur de se produire en premier lieu, lorsque Salesforce détecte la dépendance avant la suppression.DELETE_FAILEDLa version au niveau de l'enregistrement d'une suppression bloquée plutôt que réussie silencieusement dans le mauvais ordre.INVALID_CROSS_REFERENCE_KEYUn échec connexe lorsqu'une référence pointe vers quelque chose qui n'a jamais existé dans l'org cible.CANNOT_UPDATE_CONVERTED_LEADUn autre blocage basé sur l'état : l'enregistrement existe toujours, mais la conversion l'a rendu en lecture seule.

Questions fréquentes

ENTITY_IS_DELETED, les réponses

Puis-je récupérer un composant supprimé par erreur ?

S'il a été supprimé récemment, vérifiez d'abord la Recycle Bin de l'org. Les composants de métadonnées et les enregistrements y restent tous deux récupérables pendant une durée limitée.

Combien de temps un enregistrement ou un composant de métadonnées supprimé reste-t-il dans la Recycle Bin ?

Les enregistrements restent généralement récupérables pendant 15 jours avant d'être purgés définitivement ; certains types de métadonnées ont leurs propres fenêtres de rétention, donc vérifiez Setup pour le type de composant spécifique.

Interroger un enregistrement de la Recycle Bin avec ALL ROWS évite-t-il cette erreur ?

Cela peut fonctionner, pour les requêtes SOQL. Ajouter ALL ROWS permet à une requête de voir les enregistrements supprimés de façon réversible, mais toute mise à jour ou suppression DML sur ceux-ci échoue encore tant que l'enregistrement n'est pas restauré.

Commencez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.

Commencer gratuitement Réserver une démo