leapp session start very slow when SSO is required

[JacobEvelyn]

Describe the bug

The first time each day that I run leapp session start, I'm prompted to log in to AWS via Google SSO, and then the CLI command hangs for ~4 minutes before finally completing successfully. The rest of the day the command will complete in a second or two.

Leapp Version

@noovolari/leapp-cli/0.1.49 darwin-arm64 node-v21.3.0 and Leapp 0.22.2

I have also experienced this with previous versions of leapp-cli (@noovolari/leapp-cli/0.1.26 darwin-arm64 node-v20.5.0) and Leapp (not sure which versions).

To Reproduce
Steps to reproduce the behavior:

1. leapp session start --sessionId <id>
2. Default browser opens this page:

3. Press "Confirm and continue" and go to this page:

4. Press "Allow" and go to this page:

(Sometimes AWS takes me to a Google SSO page somewhere around steps 3-4, but this is not necessary to reproduce).
5. Observe that CLI command will wait for another 4 minutes before exiting with status code 0.

Expected behavior
Step 5 above to not be there. 😄

Desktop (please complete the following information):

• OS: macOS 13.6.1
• Leapp Version 0.22.2

Additional context

One member of our team reported this issue going away (i.e. the command completes right after the browser SSO login is complete) after following these instructions to install a different version of node.

[pethron]

Hello @JacobEvelyn , thanks for letting us kknow! We'll look into this performance issue, in the meanwhile refer to #500 to install the newer version of node as a workaround.

[Pat-Ayres]

Hi @pethron, I am the reporter of #500 and I just wanted to inform you that I have since started running into this problem again on a subsequent upgrade. I'm not sure exactly what mechanism causes the delay, but it is interesting to note that the timing is, afaict, always 4 minutes and 1 second for the mfa refresh. my best guess is that this means there is some code that is waiting for a signal and times out when it doesn't receive it after 4 minutes. I'm not sure which piece of the equation that could be in though since it appears to include the leapp cli, the leapp desktop application, node, and the aws cli, all of which are on uncoupled versions. Let me know if there's any further information I could provide to assist with your investigation!

[powelli]

Noticed similar behaviour when use Credential Process method. Executing commands that make use of profiles using the credential_process in ~/.aws/config file demonstrate this behaviour.

Taking the leapp session generate <guid> Leapp CLI command used in the config file also seems to prompt the same behaviour - almost exactly 4 minute delay.

Switching back to the credential file method which doesn't require the use of the Leapp CLI seems to avoid this issue - albeit with the disadvantages of using the credentials/config files.

• OS: macOS 14.2.1
• Leapp version: @noovolari/leapp-cli/0.1.56 darwin-x64 node-v21.5.0

[urz9999]

Hi @JacobEvelyn,
we have tried with different versions of node and with/without upgrading some or all the packages in the Oclif CLI to see if we could find some correlation with #500. But the two issues are unrelated. About the slow response of the CLI: it appears to be something related to node versions > 18.12.0. We use NVM and switching between versions definitively shows the "slow" behavior. What we suggest at the moment if you can, is to have nvm installed and set the version of node to 18.12.0 for the CLI; for example, you can add a .nvmrc file with the version inside. Another way could be to define an alias for the leapp command that also calls nvm use 18.12.0. Let me know if this could be a viable solution until we discover more information about it.

[JacobEvelyn]

Thanks @urz9999. Someone on our team has reported that your NVM workaround does indeed solve the issue for them. Personally it's more annoying for me to install NVM than to just work around the issue so I probably won't bother, but I appreciate you outlining the steps for anyone who needs them.

Is it possible to isolate which node function call is responsible for the 4 minute delay?

[hans-d]

Good to add this (semi?) requirement to https://docs.leapp.cloud/latest/cli/

[murshed-panorama]

I am still observing this behavior as of today, with NodeJS version 20.14.0 (LTS) and Leapp 0.25.2.

When I switch to NodeJS version 18.20.3, I get the expected behavior. So it seems like the issue was introduced somewhere between major versions 18 and 20.

[andreacavagna01]

Yeah I think adding to the doc this behaviour could be useful