Invalid Session Id - Includes workaround/fix and how to help gather diagnostic info if it recurs

Issue #2182 resolved
George Mandala created an issue

Lately I’ve been getting this weird Session Id not found errors whenever I try to generate an offline symbol table for a sandbox.

Official response

  • Scott Wells repo owner

    Based on discussions with a few folks who have had this issue and some kind folks at Salesforce proper, I have a new thought on why this might be suddenly happening. Issue #2185 describes a potential issue with OAuth connections after the rollout of the Enhanced Domains feature. Chatting with Salesforce, it sounds like this change could cause a number of issues as DNS records propagate through intermediate nameservers over time, session IDs may be associated with older login URLs and rendered invalid by new ones, etc.

    So my first suggestion is going to be to logout/login--taking into account the likely need for an explicit login URL as described in #2185--which will provide an effective workaround (and potential true fix) for this issue, then if it happens again, please help me to gather some diagnostic info as described below.

    Diagnostic Info

    Please add the following to Help>Diagnostic Tools>Debug Log Settings:

    #com.illuminatedcloud.util.CommandLineUtil
    #com.illuminatedcloud.intellij.sfdx.SfdxUtil
    #com.illuminatedcloud.intellij.builder.ForceComSfdxDeployer
    #com.illuminatedcloud.intellij.builder.ForceComSfdxRetriever
    #com.illuminatedcloud.intellij.builder.ForceComSfdxMetadataUtil
    #com.illuminatedcloud.util.VariableLengthPollingInterval
    #com.illuminatedcloud.client.ForceComApiClient
    

    Then go into Illuminated Cloud>Configure Application and, under the Connections tab, click the Force Refresh Salesforce CLI Connections toolbar button (next-to-last on the toolbar).

    Next do whatever it is that results in these invalid session ID errors. Assuming the issue reproduces, please email your idea.log* files from Help>Show Log in Explorer/Finder/Files from the full duration of this reproduction. If in doubt, just send all such files from that directory.

    Those logs are going to include the output of the Salesforce CLI force:org:list and force:org:display commands so I can see the CLI-reported access tokens for your connections plus the full details of all REST API calls made by IC2 to Salesforce so I can see the session header used for those calls. Ultimately I'm going to be trying to confirm that the access token reported by the CLI matches the session header used when calling Salesforce. If it does and the end result is the error you're reporting, it means that the CLI is reporting a stale session ID which needs to be reported to Salesforce. If they don't match, it means that IC2 is using a stale access token, and the good news is that that's completely under my control and I'll investigate/fix it.

    Please let me know if you have any questions or any issues gathering this diagnostic information. Thanks again for offering to help!

Comments (12)

  1. Scott Wells repo owner

    Hi, George. I've seen this from a few different people recently and it seems to be due to the CLI providing a stale access token, though I'd love to confirm that if possible. If this is pretty consistently reproducible for you and you don't mind taking a few minutes to help, I'd love it if you could grab some diagnostic information that would confirm that to be the case. I can tell you exactly what to do to get that info. However, if you're pressed for time--and that's TOTALLY fine if that's the case--the effective workaround is to remove and re-auth the OAuth connection as that ensures a new access token is generated for the connection by the CLI and handed over to IC2.

  2. Scott Wells repo owner

    Based on discussions with a few folks who have had this issue and some kind folks at Salesforce proper, I have a new thought on why this might be suddenly happening. Issue #2185 describes a potential issue with OAuth connections after the rollout of the Enhanced Domains feature. Chatting with Salesforce, it sounds like this change could cause a number of issues as DNS records propagate through intermediate nameservers over time, session IDs may be associated with older login URLs and rendered invalid by new ones, etc.

    So my first suggestion is going to be to logout/login--taking into account the likely need for an explicit login URL as described in #2185--which will provide an effective workaround (and potential true fix) for this issue, then if it happens again, please help me to gather some diagnostic info as described below.

    Diagnostic Info

    Please add the following to Help>Diagnostic Tools>Debug Log Settings:

    #com.illuminatedcloud.util.CommandLineUtil
    #com.illuminatedcloud.intellij.sfdx.SfdxUtil
    #com.illuminatedcloud.intellij.builder.ForceComSfdxDeployer
    #com.illuminatedcloud.intellij.builder.ForceComSfdxRetriever
    #com.illuminatedcloud.intellij.builder.ForceComSfdxMetadataUtil
    #com.illuminatedcloud.util.VariableLengthPollingInterval
    #com.illuminatedcloud.client.ForceComApiClient
    

    Then go into Illuminated Cloud>Configure Application and, under the Connections tab, click the Force Refresh Salesforce CLI Connections toolbar button (next-to-last on the toolbar).

    Next do whatever it is that results in these invalid session ID errors. Assuming the issue reproduces, please email your idea.log* files from Help>Show Log in Explorer/Finder/Files from the full duration of this reproduction. If in doubt, just send all such files from that directory.

    Those logs are going to include the output of the Salesforce CLI force:org:list and force:org:display commands so I can see the CLI-reported access tokens for your connections plus the full details of all REST API calls made by IC2 to Salesforce so I can see the session header used for those calls. Ultimately I'm going to be trying to confirm that the access token reported by the CLI matches the session header used when calling Salesforce. If it does and the end result is the error you're reporting, it means that the CLI is reporting a stale session ID which needs to be reported to Salesforce. If they don't match, it means that IC2 is using a stale access token, and the good news is that that's completely under my control and I'll investigate/fix it.

    Please let me know if you have any questions or any issues gathering this diagnostic information. Thanks again for offering to help!

  3. Scott Wells repo owner

    Oh, okay. So just refreshing took care of it? Interesting. I’ve seen some folks for whom that didn’t work meaning that it must have been picking up a stale access token from the CLI, or IC2 was holding onto an old access token even though it had gotten a fresh one from the CLI. If you see this happen again, please let me know.

    Oh, and you’ll want to remove those diagnostic logging entries as they can emit sensitive info into your debug logs.

  4. Scott Wells repo owner
    • changed status to open

    Moving this back to an open state until I feel like a full resolution is known. Also, I have new insights I'd like to share for those who encounter the issue.

  5. Xander Victory

    @Scott Wells any chance we can get a button/menu-item for reauthenticating an OAuth connection?

    The best case for me would be in the Project Connections item in the status bar, but also in the connection config panel would be good.

    This button would call the sfdx auth command with the same alias and login URL as configured initially

  6. Log in to comment