Hoe je INVALID_SESSION_ID in Salesforce-deployments oplost

De sessie-ID die wordt gebruikt om een API-aanroep te authenticeren is verlopen, ingetrokken, of nooit geldig geweest.

Treedt op bij: elke API-aanroep, meestal halverwege een langlopende deploy- of testjob

Wat het betekent

INVALID_SESSION_ID betekent dat de accesstoken die een API- of Metadata API-aanroep authenticeert niet langer geldig is, of dat nu is omdat deze is verlopen, ingetrokken, of om te beginnen geen echte sessie was. Salesforce wijst de aanroep meteen af voordat de gevraagde deployment of data-operatie wordt geprobeerd, omdat authenticatie als eerste wordt gecontroleerd.

In tegenstelling tot INVALID_LOGIN, dat de allereerste authenticatiepoging blokkeert, treft deze fout halverwege een job: de pipeline is succesvol geauthenticeerd, is begonnen met werken, en de sessie stierf ergens halverwege een langlopende deploy, testrun of Bulk API-job.

Diagnose

Veelvoorkomende oorzaken

Een langlopende job overleeft de sessietime-out

Een deployment of Apex-testrun duurt langer dan de geconfigureerde sessietime-out van de org, en de sessie verloopt halverwege de job.

De token van een connected app is ingetrokken of dwingt herauthenticatie af

Een wijziging in OAuth-beleid of handmatige intrekking maakt de token ongeldig halverwege een pipelinerun.

Een CI-job hergebruikte een gecachte sessie van een eerdere run

Een pipelinestap hergebruikt een sessie-ID die is opgeslagen van een eerdere job in plaats van vers te authenticeren, en die sessie is inmiddels verlopen.

De oplossing

Authenticeer opnieuw vlak voor langlopende jobs
Authenticeer opnieuw of vernieuw de token vlak voordat je een deploy of testrun start, in plaats van een oudere sessie te hergebruiken.
Verleng sessietime-outinstellingen waar gerechtvaardigd
Verhoog de sessietime-out in Setup voor orgs waar CI-runs daadwerkelijk langer duren dan het standaardvenster.
Vermijd het cachen van sessie-ID's tussen pipelineruns
Authenticeer per job opnieuw in plaats van een sessie-ID te bewaren en te hergebruiken tussen afzonderlijke pipeline-uitvoeringen.

In de praktijk

Hoe Serpent dit voorkomt

Serpent beheert geauthenticeerde verbindingen naar elke org centraal en vernieuwt deze automatisch, zodat een langlopende deploy of testjob niet halverwege sterft doordat een gecachte sessie eronder is verlopen. Zie de bibliotheek met Salesforce-deploymentfouten.

Org- en Git-verbindingsinstellingen in Serpent

Preventie

Gebruik een refresh-token-gebaseerde flow voor alles dat langer dan een paar minuten duurt

Geef de voorkeur aan OAuth-flows die stille tokenvernieuwing ondersteunen boven een statische sessie-ID voor jobs met een reële kans om lang te duren.

Splits zeer langlopende deploy- of testjobs op in kleinere delen

Breek een job die regelmatig de sessietime-out nadert op in kleinere opeenvolgende runs, elk met een verse authenticatie.

Sla een sessie-ID nooit op als langlevend CI-secret

Behandel een sessie-ID als eenmalig en kortlevend; sla in plaats daarvan de refresh token of JWT-credential op als het duurzame secret.

Gerelateerde fouten

INVALID_LOGINDe vroegere-fase authenticatiefout waarvan deze fout de midden-in-de-job-variant is.REQUEST_LIMIT_EXCEEDEDNog een org-brede conditie die halverwege de pipeline kan toeslaan om redenen die los staan van de inhoud van de deployment zelf.

Veelgestelde vragen

INVALID_SESSION_ID, beantwoord

Is INVALID_SESSION_ID hetzelfde als een verlopen wachtwoord?

Nee. Het gaat specifiek om de sessietoken die wordt gebruikt voor API-authenticatie, niet om de inloggegevens van de gebruiker, die onafhankelijk van welke sessie dan ook geldig blijven.

Maakt opnieuw inloggen in een ander browsertabblad mijn CI-sessie ongeldig?

Dat kan, afhankelijk van het "Lock sessions to the IP address"-beleid en het beleid voor gelijktijdige sessies van de org; een sessie die strikt aan één logincontext is gebonden, kan ongeldig worden gemaakt door een tweede, conflicterende login.

Voorkomt het asynchrone deploypatroon van de Metadata API deze fout?

Gedeeltelijk. Het starten van een async deploy en het pollen naar status met een verse sessie per poll vermindert de blootstelling, maar de oorspronkelijke sessie die is gebruikt om de deploy te starten kan nog steeds verlopen als de deploy zelf langer duurt dan de time-out.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingericht. Geen DevOps-medewerker nodig.

Start gratis Plan een demo