LoadEncryptedSessionEvent

Gets fired right after AuthManager successfully decrypts a previously saved session from disk.

Fields

SessionFilePath

The file the encrypted session was loaded from.

Accessor is capitalized

Just like SaveEncryptedSessionEvent, the record component is declared as SessionFile (capital S), so the generated accessor is event.SessionFile(), not event.sessionFile().

When it fires

Encryptor.loadEncryptedSession(...) runs inside AuthManager.loginWithSavedSession(), which you’d typically call once at launcher startup (see the Authentication guide). This event fires only after the file is successfully decrypted with the AES master key, not merely when a saved session file is found.

Two cases where it does not fire, even though loginWithSavedSession() was called:

• No session file exists yet (first run, or after hasSessionSaved() returned false): the method returns null immediately, before any decryption is attempted.
• Decryption or refreshing fails, e.g. the master key changed, the file is corrupted, or the Microsoft/Xbox token refresh call throws. loginWithSavedSession() catches the exception, logs it, and returns null without posting this event.

So in practice, this event firing is a reliable signal that the on-disk session was valid and readable. It does not by itself guarantee the session was still authorized by Microsoft, since token refreshing happens afterward and can still fail separately.

Posted to the EventBus passed to AuthManager.init(baseDir, eventBus) - see the Events introduction for how this bus relates to LaunchConfiguration’s.