Comment corriger REQUEST_LIMIT_EXCEEDED dans les déploiements Salesforce

L'org a épuisé son allocation de requêtes API, de sorte que les appels supplémentaires, y compris les opérations de déploiement, sont rejetés jusqu'à sa réinitialisation.

Se produit pendant : tout appel API, une fois l'allocation glissante de 24 heures de l'org épuisée

Ce que cela signifie

REQUEST_LIMIT_EXCEEDED signifie que l'org a épuisé sa limite de requêtes API, généralement l'allocation glissante de 24 heures, de sorte que les appels supplémentaires via REST, SOAP ou Bulk API sont rejetés jusqu'à ce que l'usage se réinitialise ou que la limite soit relevée. C'est un plafond à l'échelle de l'org, donc il peut être déclenché par n'importe quelle combinaison d'intégrations, pas seulement par le pipeline de déploiement lui-même.

L'allocation évolue selon l'édition et le nombre d'utilisateurs sous licence, donc une scratch org ou une sandbox Developer Edition avec une petite allocation fixe peut atteindre ce plafond avec un pipeline CI dimensionné pour la production, bien avant que la production elle-même ne le fasse.

Diagnostic

Causes courantes

Le pipeline CI interroge l'état avec de nombreux petits appels

Un pipeline vérifie l'état du déploiement ou du job avec de fréquentes requêtes API individuelles au lieu de les regrouper ou de les espacer.

D'autres intégrations partagent la même limite quotidienne

D'autres systèmes connectés à l'org consomment la majeure partie de l'allocation API partagée avant même que les appels propres au déploiement ne s'exécutent.

La scratch org ou la sandbox a une limite inférieure à la production

L'allocation API quotidienne plus faible d'un environnement de niveau inférieur est épuisée par un pipeline dimensionné pour un usage de production.

La solution

Regroupez les appels avec l'API Bulk ou des requêtes composites
Remplacez les appels REST individuels à haute fréquence par l'API Bulk ou l'API Composite pour réduire le nombre total de requêtes.
Surveillez l'usage et échelonnez les jobs lourds
Vérifiez l'usage de l'API sous Setup, System Overview, et planifiez les jobs lourds pour éviter qu'ils ne s'empilent sur d'autres intégrations.
```
sf data query --query "SELECT ApiCurrentUsage, ApiRequestsPerDay FROM OrganizationLimits" --target-org myOrgAlias --use-tooling-api
```
Demandez une augmentation de limite là où l'usage est légitimement élevé
Pour les orgs où un usage réel et soutenu approche régulièrement du plafond, demandez une augmentation de la limite API auprès de Salesforce.

En pratique

Comment Serpent évite cela

Serpent mutualise et réutilise les connexions entre les environnements d'une équipe plutôt que d'ouvrir une nouvelle session bavarde par tâche, ce qui maintient l'usage de l'API plus bas qu'un ensemble de jobs CI écrits indépendamment ciblant la même org. Consultez la bibliothèque des erreurs de déploiement Salesforce.

Tableau de bord des releases avec alertes de conflit dans Serpent

Prévention

Interrogez l'état du déploiement avec un backoff exponentiel, pas des intervalles courts fixes

Espacez les appels de vérification d'état avec un délai croissant plutôt que d'interroger toutes les quelques secondes, ce qui consomme rapidement l'allocation quotidienne sur les déploiements longs.

Suivez l'usage de l'API par intégration, pas seulement à l'échelle de l'org

Identifiez quelle application connectée ou quel compte de service consomme le plus d'appels, afin qu'une intégration incontrôlée soit repérée avant qu'elle n'affame le pipeline de déploiement.

Dimensionnez le volume d'appels CI à l'allocation réelle de l'environnement

Vérifiez la limite API quotidienne spécifique d'une scratch org ou d'une sandbox avant de supposer qu'un pipeline dimensionné pour la production y tiendra.

Erreurs associées

LIMIT_EXCEEDEDLa famille plus large des limites Salesforce, y compris les limites gouverneur par transaction, dont cette erreur spécifique à l'API fait partie.INVALID_SESSION_IDUn autre échec en cours de pipeline, sans rapport avec le contenu propre du déploiement.

Questions fréquentes

REQUEST_LIMIT_EXCEEDED, expliqué

Cette limite se réinitialise-t-elle à minuit dans le fuseau horaire de mon org ?

C'est une fenêtre glissante de 24 heures basée sur l'usage, pas une réinitialisation fixe à minuit, donc l'heure exacte de réinitialisation dépend du moment où les appels ont été effectués à l'origine.

L'API Metadata utilisée pour les déploiements compte-t-elle sur la même limite que les appels API REST ?

Oui. Les appels Metadata API, REST, SOAP, Bulk et Tooling API puisent tous dans la même allocation quotidienne à l'échelle de l'org, donc une intégration de données lourde peut épuiser la limite qu'un déploiement ne pourra plus utiliser ensuite.

Puis-je vérifier les appels API restants avant le début d'un déploiement ?

Oui, interrogez l'objet OrganizationLimits via la Tooling API, ou consultez Setup, System Overview, pour connaître l'usage actuel et l'allocation quotidienne avant de lancer un job important.

Démarrez gratuitement. Pas de carte bancaire, pas d'installation, pas d'engagement.

Configuration en moins de 15 minutes. Aucun recrutement DevOps nécessaire.

Essai gratuit Réservez une démo