Comment corriger CIRCULAR_DEPENDENCY dans les déploiements Salesforce

Deux composants de métadonnées ou plus se référencent mutuellement, ce qui empêche Salesforce de déterminer un ordre de déploiement valide.

Apparaît pendant : la validation du déploiement des métadonnées, avant l'exécution de tout test

Ce que cela signifie

CIRCULAR_DEPENDENCY survient lorsque deux composants, le plus souvent des classes Apex, des enregistrements de métadonnées personnalisées ou des types d'enregistrement, exigent chacun l'existence préalable de l'autre. L'API Metadata déploie les composants dans l'ordre des dépendances, et un cycle signifie qu'aucun ordre valide ne satisfait les deux à la fois.

Apex est le déclencheur le plus courant car le compilateur résout les références de classes au moment du déploiement : si la signature de la Classe A référence la Classe B et que la signature de la Classe B référence la Classe A, aucune des deux ne peut être compilée seule en premier, uniquement ensemble dans la même transaction de déploiement.

Diagnostic

Causes courantes

Deux classes Apex référencent mutuellement leurs méthodes

La Classe A appelle une méthode de la Classe B, et la Classe B appelle une méthode de la Classe A, donc aucune des deux ne peut être compilée avant que l'autre n'existe.

Des types de métadonnées personnalisées se référencent mutuellement

Un enregistrement de métadonnées personnalisées du Type A stocke une référence vers un enregistrement du Type B, et un enregistrement du Type B référence en retour le Type A.

Des types d'enregistrement référencent mutuellement leurs valeurs de liste de sélection

Deux types d'enregistrement sur des objets liés restreignent chacun une liste de sélection à des valeurs contrôlées par le type d'enregistrement de l'autre, créant une boucle que le déploiement ne peut pas résoudre.

La solution

Déployez d'abord un stub pour briser le cycle
Déployez un côté de la paire avec une implémentation minimale ou vide, puis déployez la logique réelle lors d'une seconde passe.
Combinez les deux composants en un seul déploiement
Regroupez les classes ou métadonnées interdépendantes dans un seul déploiement afin que Salesforce résolve l'ensemble ensemble plutôt que de les ordonner individuellement.
```
sf project deploy start --source-dir force-app/main/default/classes/ClassA.cls force-app/main/default/classes/ClassB.cls
```
Refactorez pour supprimer la référence mutuelle
Extrayez la logique partagée dans une troisième classe ou interface afin qu'aucun des composants d'origine ne dépende directement de l'autre.

En pratique

Comment Serpent évite cela

Serpent suit les composants touchés par une tâche et signale les composants interdépendants avant qu'ils ne soient répartis entre des tâches distinctes, de sorte qu'une paire circulaire se déploie ensemble au lieu d'échouer à mi-chemin. Consultez la bibliothèque des erreurs de déploiement Salesforce.

Constructeur de pipelines CI/CD no-code dans Serpent

Prévention

Concevez dès le départ une base ou une interface commune pour la logique partagée

Lorsque deux classes doivent s'appeler mutuellement, extrayez le contrat partagé dans une interface ou une classe utilitaire dès le départ plutôt que de câbler des références directes.

Ne divisez jamais une paire mutuellement dépendante entre des tâches distinctes

Gardez les composants qui se référencent mutuellement dans la même branche et la même unité de déploiement afin qu'ils ne soient jamais promus indépendamment.

Cartographiez les références croisées avant de concevoir des relations de métadonnées personnalisées

Esquissez le sens des références entre types de métadonnées personnalisées avant de les construire, afin qu'une dépendance bidirectionnelle soit détectée sur le papier, pas au moment du déploiement.

Erreurs associées

DUPLICATE_DEVELOPER_NAMEUn autre conflit de nommage de métadonnées fréquent en développement parallèle.INVALID_CROSS_REFERENCE_KEYUne version unidirectionnelle du même problème sous-jacent : une référence que l'org cible ne peut pas résoudre.

Questions fréquentes

CIRCULAR_DEPENDENCY, expliqué

Diviser un déploiement en change sets plus petits corrige-t-il CIRCULAR_DEPENDENCY ?

Non, cela aggrave généralement la situation. Diviser des composants interdépendants entre des déploiements séparés est précisément ce qui crée le cycle au départ ; les regrouper en un seul déploiement est la solution.

Trois composants ou plus peuvent-ils former une dépendance circulaire, pas seulement deux ?

Oui. Un cycle de n'importe quelle longueur, A dépend de B, B dépend de C, C dépend à nouveau de A, déclenche la même erreur ; la solution reste de déployer tout le cycle ensemble.

Le CLI Salesforce résout-il automatiquement les dépendances Apex circulaires ?

Non. Le CLI déploie l'ensemble de fichiers que vous lui indiquez en une seule transaction ; il ne réordonne ni ne crée de stubs pour vous, donc les deux côtés de la paire doivent être inclus explicitement.

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