Webstorm Freezing

[Justin Julicher]

Attached the logs.

Not sure what is happening but WS is locking up about once a day now.

Node Version: 13.9.0

sfdx-cli@7.52.0

‌

‌

[Scott Wells]

It's not actually a deadlock. It's happening because sfdx force:org:list is running long. Coincidentally I'll be releasing a build tomorrow morning that will provide persistent caching of force:org:list and force:org:display results to help with this and other performance issues related to invoking the CLI for connection information. However, even with caching force:org:list can run long when things get....crufty. Here's how to get things back into a better state (extracted from tomorrow's build's release notes):

Hopefully this will result in far less frequent invocations of these two CLI commands. Note that if force:org:list is still taking considerable time to run, the following command-line actions may help significantly:

1. Run sfdx force:org:list --clean to remove all stale scratch org connections.
2. Run sfdx force:org:list and, for every non-scratch org connection with a value for CONNECTED STATUS that is not Connected, run sfdx force:auth:logout -u <username>.
3. Use force:auth:logout to log out of any other non-scratch org connections that you are no longer using.

Let me know if that doesn't help.

[Justin Julicher]

Hi Scott

thanks for that. I’ve done what you suggested and hopefully that will resolve my issue for the time being. It did happen during a cleanup of all our sandboxes - so I did have a couple of invalid connections.

Is there any way you could cancel the current operation if say the sfdx org list function went on for longer than 30 seconds? Maybe make it a config option if possible and maybe suggest what you said in a popup? Or better yet Give a dialog to the user to select ones to remove and run the force:auth:logout command for them

‌

Hope you and your family are staying safe & healthy during this COVID-19 outbreak!

[Scott Wells]

Justin, I've just published 2.1.1.2 which should help with this considerably, at least in terms of frequency of execution of force:org:list and force:org:display.

Unfortunately I can't really add a cancel button to these dialogs because they are synchronous and the other side of the operation requires the correct results of these CLI executions. If you were to cancel and an empty result were to be returned, IC would treat that as a misconfigured module incorrectly.

I've been working with the Salesforce DX team on this problem and they are aware that the runtime of these two commands can get (excruciatingly) long. They have some ideas on how to address it, so I'd prefer to have this front-line caching provide the relief that it can until they produce a better fix in the CLI proper.

I have considered adding a feature to IC to help clean up stale connections, specifically when IC detects that CLI runtimes are long and it sees stale/expired connections in the results of these commands. I may yet do that.

And thanks for the good health wishes! Same to you!

[Scott Wells]

I'm going to resolve this for now based on the changes in 2.1.1.2. As I mentioned, there will likely(/hopefully) be more improvements here from both Salesforce and IC in the relatively near future.