Comment corriger INVALID_SESSION_ID dans les déploiements Salesforce

L'ID de session utilisé pour authentifier un appel API a expiré, a été révoqué, ou n'a jamais été valide.

Se manifeste lors de : tout appel API, le plus souvent en plein milieu d'un déploiement ou d'un test de longue durée

Ce que cela signifie

INVALID_SESSION_ID signifie que le jeton d'accès authentifiant un appel API ou Metadata API n'est plus valide, que ce soit parce qu'il a expiré, a été révoqué, ou n'était pas une vraie session au départ. Salesforce rejette l'appel d'emblée avant même de tenter le déploiement ou l'opération de données demandée, car l'authentification est vérifiée en premier.

Contrairement à INVALID_LOGIN, qui bloque la toute première tentative d'authentification, cette erreur frappe en cours de job : le pipeline s'est authentifié avec succès, a commencé à travailler, et la session est morte quelque part au milieu d'un déploiement, d'un test, ou d'un job Bulk API de longue durée.

Diagnostic

Causes courantes

Un job de longue durée dépasse le délai d'expiration de la session

Un déploiement ou un test Apex prend plus de temps que le délai de session configuré de l'org, et la session expire en cours de job.

Le jeton d'une application connectée a été révoqué ou force une réauthentification

Un changement de politique OAuth ou une révocation manuelle invalide le jeton en cours d'exécution du pipeline.

Un job CI a réutilisé une session mise en cache d'une exécution précédente

Une étape du pipeline réutilise un ID de session stocké d'un job antérieur au lieu de se réauthentifier, et cette session a depuis expiré.

La solution

Se réauthentifier juste avant les jobs de longue durée
Réauthentifiez-vous ou rafraîchissez le jeton juste avant de lancer un déploiement ou un test plutôt que de réutiliser une session plus ancienne.
Étendre les délais d'expiration de session lorsque c'est justifié
Augmentez le délai d'expiration de session dans Setup pour les orgs où les exécutions CI prennent réellement plus de temps que la fenêtre par défaut.
Éviter de mettre en cache les ID de session entre les exécutions du pipeline
Réauthentifiez-vous par job plutôt que de conserver et réutiliser un ID de session entre des exécutions de pipeline distinctes.

En pratique

Comment Serpent évite cela

Serpent gère les connexions authentifiées à chaque org de façon centralisée et les rafraîchit automatiquement, afin qu'un déploiement ou test de longue durée ne meure pas en cours de route parce qu'une session en cache a expiré dessous. Voir la bibliothèque des erreurs de déploiement Salesforce.

Paramètres de connexion Org et Git dans Serpent

Prévention

Utiliser un flux basé sur un jeton de rafraîchissement pour tout ce qui dure plus de quelques minutes

Préférez les flux OAuth prenant en charge le rafraîchissement silencieux de jeton à un ID de session statique pour les jobs susceptibles de durer longtemps.

Diviser les jobs de déploiement ou de test très longs en morceaux plus petits

Découpez un job qui approche régulièrement du délai d'expiration de session en exécutions séquentielles plus petites, chacune se réauthentifiant.

Ne jamais conserver un ID de session comme secret CI à longue durée de vie

Traitez un ID de session comme à usage unique et éphémère ; stockez plutôt le jeton de rafraîchissement ou l'identifiant JWT comme secret durable.

Erreurs associées

INVALID_LOGINL'échec d'authentification à un stade antérieur dont cette erreur est la cousine en cours de job.REQUEST_LIMIT_EXCEEDEDUne autre condition à l'échelle de l'org qui peut frapper en plein milieu du pipeline pour des raisons sans rapport avec le contenu du déploiement lui-même.

Questions fréquentes

INVALID_SESSION_ID, expliqué

INVALID_SESSION_ID est-il la même chose qu'un mot de passe expiré ?

Non. Il s'agit spécifiquement du jeton de session utilisé pour l'authentification API, pas des identifiants de connexion de l'utilisateur, qui restent valides indépendamment de toute session.

Se reconnecter dans un autre onglet du navigateur invalide-t-il ma session CI ?

Cela peut arriver, selon les politiques "Lock sessions to the IP address" et de sessions concurrentes de l'org ; une session strictement liée à un contexte de connexion peut être invalidée par une seconde connexion conflictuelle.

Le modèle de déploiement asynchrone de l'API Metadata évite-t-il cette erreur ?

Partiellement. Lancer un déploiement asynchrone et interroger le statut avec une nouvelle session à chaque sondage réduit l'exposition, mais la session originale utilisée pour démarrer le déploiement peut quand même expirer si le déploiement lui-même dure plus longtemps que le délai.

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

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

Démarrer gratuitement Réserver une démo