So beheben Sie INVALID_SESSION_ID in Salesforce-Deployments

Die zur Authentifizierung eines API-Aufrufs verwendete Sitzungs-ID ist abgelaufen, wurde widerrufen oder war nie gültig.

Tritt auf bei: jedem API-Aufruf, meist mitten in einem lang laufenden Deployment- oder Testjob

Was das bedeutet

INVALID_SESSION_ID bedeutet, dass das Zugriffstoken, das einen API- oder Metadata-API-Aufruf authentifiziert, nicht mehr gültig ist, sei es weil es abgelaufen ist, widerrufen wurde oder von vornherein keine echte Sitzung war. Salesforce lehnt den Aufruf sofort ab, bevor das angeforderte Deployment oder der Datenvorgang überhaupt versucht wird, da die Authentifizierung zuerst geprüft wird.

Anders als INVALID_LOGIN, das bereits den allerersten Authentifizierungsversuch blockiert, tritt dieser Fehler mitten im Job auf: Die Pipeline hat sich erfolgreich authentifiziert, mit der Arbeit begonnen, und die Sitzung starb irgendwo mitten in einem lang laufenden Deployment, Testlauf oder Bulk-API-Job.

Diagnose

Häufige Ursachen

Ein lang laufender Job überdauert das Sitzungs-Timeout

Ein Deployment oder ein Apex-Testlauf dauert länger als das konfigurierte Sitzungs-Timeout der Org, und die Sitzung läuft mitten im Job ab.

Das Token einer verbundenen App wurde widerrufen oder erzwingt eine erneute Authentifizierung

Eine Änderung der OAuth-Richtlinie oder ein manueller Widerruf macht das Token mitten in einem Pipeline-Lauf ungültig.

Ein CI-Job hat eine zwischengespeicherte Sitzung aus einem früheren Lauf wiederverwendet

Ein Pipeline-Schritt verwendet eine aus einem früheren Job gespeicherte Sitzungs-ID wieder, statt sich neu zu authentifizieren, und diese Sitzung ist inzwischen abgelaufen.

Die Lösung

Direkt vor lang laufenden Jobs neu authentifizieren
Authentifizieren Sie sich neu oder aktualisieren Sie das Token unmittelbar vor dem Start eines Deployments oder Testlaufs, statt eine ältere Sitzung wiederzuverwenden.
Sitzungs-Timeout-Einstellungen bei berechtigtem Bedarf verlängern
Erhöhen Sie das Sitzungs-Timeout in Setup für Orgs, in denen CI-Läufe tatsächlich länger dauern als das Standardfenster.
Zwischenspeichern von Sitzungs-IDs über Pipeline-Läufe hinweg vermeiden
Authentifizieren Sie sich pro Job neu, statt eine Sitzungs-ID zwischen separaten Pipeline-Ausführungen zu speichern und wiederzuverwenden.

In der Praxis

Wie Serpent das verhindert

Serpent verwaltet authentifizierte Verbindungen zu jeder Org zentral und aktualisiert sie automatisch, sodass ein lang laufendes Deployment oder ein Testjob nicht mittendrin abstirbt, weil eine zwischengespeicherte Sitzung darunter abgelaufen ist. Siehe die Bibliothek der Salesforce-Deployment-Fehler.

Org- und Git-Verbindungseinstellungen in Serpent

Prävention

Für alles, was länger als ein paar Minuten läuft, einen Refresh-Token-basierten Ablauf verwenden

Bevorzugen Sie OAuth-Abläufe mit stiller Token-Erneuerung gegenüber einer statischen Sitzungs-ID für Jobs mit realer Chance auf lange Laufzeit.

Sehr lange Deployment- oder Testjobs in kleinere Teile aufteilen

Teilen Sie einen Job, der regelmäßig an das Sitzungs-Timeout heranreicht, in kleinere aufeinanderfolgende Läufe auf, die sich jeweils neu authentifizieren.

Eine Sitzungs-ID niemals als langlebiges CI-Secret speichern

Behandeln Sie eine Sitzungs-ID als einmalig und kurzlebig; speichern Sie stattdessen den Refresh-Token oder die JWT-Anmeldedaten als dauerhaftes Secret.

INVALID_SESSION_ID, beantwortet

Ist INVALID_SESSION_ID dasselbe wie ein abgelaufenes Passwort?

Nein. Es geht speziell um das für die API-Authentifizierung verwendete Sitzungstoken, nicht um die Anmeldedaten des Nutzers, die unabhängig von einer einzelnen Sitzung gültig bleiben.

Macht ein erneutes Anmelden in einem anderen Browser-Tab meine CI-Sitzung ungültig?

Das kann passieren, je nach den Richtlinien "Lock sessions to the IP address" und den Richtlinien für gleichzeitige Sitzungen der Org; eine strikt an einen Anmeldekontext gebundene Sitzung kann durch eine zweite, widersprüchliche Anmeldung ungültig werden.

Vermeidet das asynchrone Deployment-Muster der Metadata API diesen Fehler?

Teilweise. Ein asynchrones Deployment zu starten und den Status bei jeder Abfrage mit einer frischen Sitzung abzufragen, verringert die Gefährdung, aber die ursprüngliche Sitzung, die zum Starten des Deployments verwendet wurde, kann trotzdem ablaufen, wenn das Deployment selbst länger dauert als das Timeout.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

Einrichtung in unter 15 Minuten. Keine DevOps-Einstellung nötig.

Kostenlos starten Demo buchen