ZoweExplorerZosmfApi.getSession returning undefined in cases

[JillieBeanSim]

Describe the bug

referenced in PR where sometimes getSession is returning undefined or passed undefined to new VSC Proxy method ProfilesCache.getProfileSessionWithVscProxy. This needs to be investigated and fixed as getSession should always return a zosmf session.

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[zFernand0]

You might be able to use a profile like the one below to replicate the problem.
If you don't have a token stored on that profile, we don't add the tokenType to the session

https://github.com/zowe/zowe-explorer-vscode/blob/main/packages/zowe-explorer-api/src/profiles/ZoweExplorerZosmfApi.ts#L73

Thus, we treat it as if it was using basic auth 😋

        "apiml": {
            "type": "zosmf",
            "properties": {
                "host": "lpar.dev",
                "port": 7554,
                "basePath": "/ibmzosmf/api/v1",
                "tokenType": "apimlAuthenticationToken"
            },
            "secure": [
                "tokenValue"
            ]
        },

[traeok]

While this function does return undefined, this appears to be by design:

• When a profile has an invalid hostname, it fails to create a session for a profile node, and thus the session node property is undefined
• We have error handling in place to catch any errors from the imperative.Session constructor (as the constructor can throw exceptions)
• We have checks elsewhere in the codebase to see if the node's session is falsy before continuing

Since the ISession TypeError was resolved in #3428, should we close this as not planned?

[zFernand0]

Since the ISession TypeError was resolved in #3428, should we close this as not planned?

I'm not opposed to that idea (since it does seem to be by design) 😅