System.UserInfo.getSessionId() throws System.UnexpectedException

[krishnandusarkarprax]

Package Edition of Nebula Logger

Unlocked Package

Package Version of Nebula Logger

4.13.17

New Bug Summary

Package Edition of Nebula Logger
Unlocked Package

Package Version of Nebula Logger
4.13.17

New Bug Summary
When a user logs in through a server-to-server connected app with the setting "Issue JSON Web Token (JWT)-based access tokens for named users" enabled tries to use a Logger.xxx method, a Salesforce System Error is thrown.

Debugging reveals that the issue occurs when System.UserInfo.getSessionId() is called. Even with a try/catch block around this call, the code doesn't reach the catch block; instead, the error is thrown directly.

The only workaround is to disable the "Issue JSON Web Token (JWT)-based access tokens for named users" setting.

Defect #598 was reported a few months ago, leading to the resolution of adding a try/catch block around this code. However, despite the latest Salesforce Release (Winter '25) and Nebula Logger (version 4.13.17), the issue persists.

[jongpie]

@krishnandusarkarprax thanks for reporting this! Trying to get the user's session has been such a headache for years (issues #97 is another example where this came up ~3 years ago), and I haven't run into this particular issue myself before, so I appreciate the info & context.

Is it feasible for you to add this code snippet somewhere in your org (either in the Logger class somewhere, or one of your own Apex classes)? It just needs to be added in some Apex method that would be called in your scenario when you're using the setting "Issue JSON Web Token (JWT)-based access tokens for named users"

Integer currentSessionCount = [
    SELECT COUNT() FROM AuthSession
    WHERE UsersId = :System.UserInfo.getUserId() AND IsCurrent = TRUE
];
System.debug('Count of current sessions for the current user: ' + currentSessionCount);

If you're able to add that & run it, let me know what output you see. I'm wondering if the count will be 0 or 1 in this situation. If it ends up being 0, then I might be able to run that query first, and not call System.UserInfo.getSessionId() to avoid the uncatchable System.UnexpectedException error.