Connection list is empty
Connection list is often empty, although sfdx force:org:list in command line returns them correctly. I have recently upgraded Webstorm to 2020.1.1 and sfdx-cli to 7.56.1
Official response
Comments (52)
-
reporter -
Account Deactivated I’m running into this issue as well with the latest CLI update. I wonder if the changes to
sfdx force:org:list
has something to do about it: https://developer.salesforce.com/media/salesforce-cli/releasenotes.html -
repo owner Yes, I heard about these changes from Salesforce last night. They should be 100% backward-compatible, but I'm now hearing about this from three users so I'll be investigating this immediately. More info to come soon here.
-
repo owner Can one of you experiencing this issue please enable debug logging for Salesforce DX and force the connection list to reset using the Refresh button in the IC connection manager, then either attach the resulting
idea.log
or email it to support@illuminatedcloud.com? -
reporter - attached idea.log.zip
-
reporter @Scott Wells I have attached my log. I refreshed as you said but my list is not empty. I am not sure when the list is cleared.
-
repo owner Thanks, Kostas. Just so I understand, are you saying that you see the SFDX-based connections in the connection manager but not anywhere else? I'm just trying to understand the behavior that you're seeing.
-
Account Deactivated A quick temporary workaround that worked for me is downgrading to the previous
salesforcedx
version and then refreshing the connection list:sfdx plugins:install salesforcedx@48.10.1
-
repo owner Okay. One more request for those of you having this issue. Can you please run
sfdx force:org:list --json
on both the downgraded version that works and the latest version that does not and send me the output of both commands for review? Feel free to redact any information you'd like, but please leave the overall JSON document structure intact so I can see what structural changes might have been introduced that could be leading to this issue. -
repo owner FYI, I just did the same and the only material difference I see in the output aside from some different attribute ordering is a warning about stale connections. I'll be curious to see what you all have that's different and could be causing the issue.
-
Account Deactivated @Scott Wells I’ve emailed you the json output on the latest version, which might be all that you need since it outputs a pretty ugly error. Running the same command on a downgraded version gives you what you would expect
-
repo owner Thanks, Cesar. Yes, that's definitely the issue. I'll provide this information to Salesforce right now, but in the interim the workaround for those experiencing this issue is going to be downgrading to the previous version as you specified a few comments above. I'll repeat it here and pin this to the top:
sfdx plugins:install salesforcedx@48.10.1
Once I hear that Salesforce has issued a fix, I'll provide an all-clear here.
-
reporter @Scott Wells When connection manager has empty list, it is empty in all places within Webstorm. In command line, it always return the correct list.
-
Here’s a new scratch org from that JSON:
{ "username": "test-hbirsipk765d@example.com", "orgId": "00D0U000000EqBiUAK", "accessToken": "yyy", "instanceUrl": "https://speed-page-1717-dev-ed.cs97.my.salesforce.com", "loginUrl": "https://CS97.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS97", "created": "1586341520091", "devHubUsername": "xxx", "isDevHub": false, "expirationDate": "2020-05-08", "lastUsed": "2020-05-05T14:37:59.115Z", "status": "Active", "isExpired": false, "signupUsername": "test-hbirsipk765d@example.com", "createdBy": "xxx", "createdDate": "2020-04-08T10:25:11.000+0000", "devHubOrgId": "00D1a000000Xn5kEAC", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4J0000008V3NWAU" }, "orgName": "XX-XX", "edition": "Developer", "connectedStatus": "Unknown" }
Here’s the same scratch org in the old format:
{ "username": "test-hbirsipk765d@example.com", "orgId": "00D0U000000EqBiUAK", "accessToken": "yyy", "instanceUrl": "https://speed-page-1717-dev-ed.cs97.my.salesforce.com", "loginUrl": "https://CS97.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS97", "created": "1586341520091", "devHubUsername": "xxx", "isDevHub": false, "expirationDate": "2020-05-08", "connectedStatus": "Unknown", "lastUsed": "2020-05-05T14:37:59.115Z", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4J0000008V3NWAU" }, "orgName": "XX-XX", "status": "Active", "createdBy": "xxx", "createdDate": "2020-04-08T10:25:11.000+0000", "edition": "Developer", "signupUsername": "test-hbirsipk765d@example.com", "devHubOrgId": "00D1a000000Xn5kEAC", "isExpired": false }
-
repo owner It sounds like perhaps Kostas and Aidan are not seeing the same thing as Cesar. For Cesar running
sfdx force:org:list --json
results in the following:{ "status": 1, "name": "TypeError", "message": "Cannot read property 'SignupUsername' of undefined", "exitCode": 1, "commandName": "OrgListCommand", "stack": "TypeError: Cannot read property 'SignupUsername' of undefined\n at orgs.forEach.scratchOrgInfo (C:\\Users\\<username>\\AppData\\Local\\sfdx\\node_modules\\salesforce-alm\\dist\\lib\\org\\orgListUtil.js:245:60)\n at Array.forEach (<anonymous>)\n at Function.reduceScratchOrgInfo (C:\\Users\\<username>\\AppData\\Local\\sfdx\\node_modules\\salesforce-alm\\dist\\lib\\org\\orgListUtil.js:243:14)\n at Function.readLocallyValidatedMetaConfigsGroupedByOrgType (C:\\Users\\<username>\\AppData\\Local\\sfdx\\node_modules\\salesforce-alm\\dist\\lib\\org\\orgListUtil.js:59:46)\n at process._tickCallback (internal/process/next_tick.js:68:7)\nOuter stack:\n at Function.wrap (C:\\Users\\<username>\\AppData\\Local\\sfdx\\node_modules\\salesforce-alm\\node_modules\\@salesforce\\command\\node_modules\\@salesforce\\core\\lib\\sfdxError.js:151:27)\n at OrgListCommand.catch (C:\\Users\\<username>\\AppData\\Local\\sfdx\\node_modules\\salesforce-alm\\node_modules\\@salesforce\\command\\lib\\sfdxCommand.js:255:67)\n at process._tickCallback (internal/process/next_tick.js:68:7)", "warnings": [] }
The old and new outputs provided by Aidan are identical aside from attribute reordering. Is there nothing else in the overall output that's different outside of any individual org?
-
repo owner Downgrading and upgrading in an attempt to provide more diagnostic info seems to have resolved this issue for Aidan. Kostas, assuming this is still happening to you, could you please provide the output of
sfdx force:org:list --json
from both 48.10.1 and 48.12.1 for comparison? -
reporter @Scott Wells 48.10.1
{ "username": "6_110-025826155c93@xxx.net", "orgId": "00D2D0000008vB6UAI", "accessToken": "ddd751dddad74", "instanceUrl": "https://data-app-7569-dev-ed.cs69.my.salesforce.com/", "loginUrl": "https://CS69.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS69", "created": "1588658200313", "devHubUsername": "xxxx", "isDevHub": false, "expirationDate": "2020-05-19", "connectedStatus": "Unknown", "lastUsed": "2020-05-05T06:19:40.518Z", "alias": "6_110", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4Q000000HjigWAC" }, "orgName": "IPfolio", "status": "Active", "createdBy": "xxxxx", "createdDate": "2020-05-05T05:56:05.000+0000", "edition": "Developer", "signupUsername": "6_110-025826155c93@xxx.net", "devHubOrgId": "00D30000001xxxxEAS", "isExpired": false }
48.12.1
{ "username": "6_110-025826155c93@xxxx.net", "orgId": "00D2D0000008vB6UAI", "accessToken": "ddd751dddad74:e63e4b6189901fa4e78b1767881dad74", "instanceUrl": "https://data-app-7569-dev-ed.cs69.my.salesforce.com/", "loginUrl": "https://CS69.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS69", "created": "1588658200313", "devHubUsername": "xxxxx", "isDevHub": false, "expirationDate": "2020-05-19", "alias": "6_110", "lastUsed": "2020-05-05T06:19:40.518Z", "status": "Active", "isExpired": false, "signupUsername": "6_110-025826155c93@ipfolio.net", "createdBy": "xxxxx", "createdDate": "2020-05-05T05:56:05.000+0000", "devHubOrgId": "00D30000001xxxxEAS", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4Q000000HjigWAC" }, "orgName": "IPfolio", "edition": "Developer", "connectedStatus": "Unknown" }
-
repo owner Is the output of 48.12.1 complete? It seems truncated.
-
reporter I posted one scratch org entry. Should I post all of them?
-
repo owner I need to see the full output for
force:org:list --json
on the older version and the newer version. Ideally these would be extracted from IC's debug log, but let's start by just looking at the output of the two versions to see if there are any differences that might lead to this issue. -
repo owner Issue
#1607was marked as a duplicate of this issue. -
Update: Ensuring all my scratch orgs are given aliases seems to have resolved this issue for me.
I'm experiencing what seems like the same issue. Occasionally IC2 sees my org by its alias, but most of the time its only the org’s username which appears in the connection list. This seems to be flickering with some Webstorm restarts, and causes havoc with IC2 losing connection / symbol table / causing constant indexing etc. I do however see other orgs in the connection list.
Windows 10 x64
Webstorm 2020.1.1
IC2 2.1.1.8
sfdx --version
sfdx-cli/7.56.1-2773b53bf5 win32-x64 node-v10.15.3sfdx plugins --core
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.2.3 (core)
@oclif/plugin-help 2.2.3 (core)
@oclif/plugin-not-found 1.2.3 (core)
@oclif/plugin-plugins 1.7.9 (core)
@oclif/plugin-update 1.3.9 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.0.7 (core)
analytics 1.7.1 (core)
generator 1.1.2 (core)
isvte-sfdx-plugin 1.1.2
salesforcedx 48.12.1
├─ @salesforce/sfdx-plugin-lwc-test 0.1.5
├─ salesforcedx-templates 48.10.0
└─ salesforce-alm 48.12.0sfdx-cli 7.56.1 (core)
I downgraded and re-upgraded but it has not resolved the issue. I didn’t see any differences between the sfdx force:org:list --json output apart from property ordering, and a new property
"defaultMarker": "(U)"
which seems to flag orgs without an alias? This isn’t in the release notes.But having enabled logging in IC2 I see that the output of sfdx force:org:list --json was completely different when IC2 ran it:
Command Line:
{ "status": 0, "result": { "nonScratchOrgs": [ ], "scratchOrgs": [ { "username": "test-redacted@example.com", "orgId": "redacted", "accessToken": "redacted", "instanceUrl": "https://redacted.cs81.my.salesforce.com", "loginUrl": "https://CS81.salesforce.com", "password": "redacted", "clientId": "redacted", "createdOrgInstance": "CS81", "created": "1587379114272", "devHubUsername": "redacted", "expirationDate": "2020-05-20", "lastUsed": "2020-05-01T11:31:25.518Z", "isDefaultUsername": true, "status": "Active", "isExpired": false, "signupUsername": "redacted", "createdBy": "redacted", "createdDate": "2020-04-20T10:38:26.000+0000", "devHubOrgId": "redacted", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4G000000GqGwWAK" }, "orgName": "redacted", "edition": "Developer", "connectedStatus": "Unknown", "defaultMarker": "(U)" }, { "username": "test-redacted@example.com", "orgId": "redacted", "accessToken": "redacted", "instanceUrl": "https://redacted.cs87.my.salesforce.com", "loginUrl": "https://CS87.salesforce.com", "password": "redacted", "clientId": "redacted", "createdOrgInstance": "CS87", "created": "1588609635301", "devHubUsername": "redacted", "isDevHub": false, "expirationDate": "2020-05-11", "alias": "redacted", "lastUsed": "2020-05-06T11:27:04.233Z", "status": "Active", "isExpired": false, "signupUsername": "redacted", "createdBy": "redacted", "createdDate": "2020-05-04T16:27:09.000+0000", "devHubOrgId": "redacted", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4G000000GqMzWAK" }, "orgName": "redacted", "edition": "Developer", "connectedStatus": "Unknown" } ] } }
IC2 Log:
{ "status": 0, "result": { "nonScratchOrgs": [ ], "scratchOrgs": [ { "username": "test-redacted@example.com", "orgId": "redacted", "accessToken": "redacted", "instanceUrl": "https://redacted.cs81.my.salesforce.com", "loginUrl": "https://CS81.salesforce.com", "password": "redacted", "clientId": "redacted", "createdOrgInstance": "CS81", "created": "1587379114272", "devHubUsername": "redacted", "expirationDate": "2020-05-20", "lastUsed": "2020-05-01T11:31:25.518Z", "isDefaultUsername": true, "status": "Active", "isExpired": false, "signupUsername": "test-redacted@example.com", "createdBy": "redacted", "createdDate": "2020-04-20T10:38:26.000+0000", "devHubOrgId": "redacted", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR4G000000GqGwWAK" }, "orgName": "redacted", "edition": "Developer", "connectedStatus": "Unknown", "defaultMarker": "(U)" }, { "username": "test-redacted@example.com", "orgId": "redacted", "accessToken": "redacted", "refreshToken": "redacted", "instanceUrl": "https://redacted.cs87.my.salesforce.com", "loginUrl": "https://CS87.salesforce.com", "password": "redacted", "clientId": "redacted", "clientSecret": "redacted", "createdOrgInstance": "CS87", "created": "1588609635301", "devHubUsername": "redacted", "isDevHub": false, "expirationDate": "2020-05-11", "status": "Active", "isExpired": false } ] } }
Main obvious things being that the alias is missing but other properties are also added and removed. I’ve run sfdx force:org:list --json from the command line many times and not seen this. Does IC2 set some environment variables?
I have about 10 non-scratch orgs which I deleted out of the above logs but can share if needed, I didn’t spot any notable differences.
-
repo owner James, that's very helpful. Certainly the missing alias is curious. IC2 does set two environment variables:
SFDX_AUTOUPDATE_DISABLE=true
andSFDX_JSON_TO_STDOUT=true
. You can see the exact invocation by enabling Log Salesforce DX commands in the Salesforce DX application-level configuration settings. They're sent to a Messages window.So if I understand correctly, this problem only exists on the latest CLI build, correct? Or did you see the same issues after downgrading to the previous release as well?
-
Thanks Scott. I’m not certain but I think I saw the issue with both 48.12.1 and 48.10.1. I’ve tried to reproduce the issue to validate it against both versions, but can’t now get it to happen again. Will update if it reoccurs.
-
repo owner Thanks, James. For all who are seeing this issue, the prevailing thought right now is that sometimes--but not always--the execution of
sfdx force:org:list --json
does not include configured aliases in the output. I have actually observed this once myself, and when I forced IC to refresh the connection list the usernames changed to aliases.I'm going to try to reproduce this for a bit with debug logging turned on so I can hopefully see the proverbial smoking gun. If any of you who are seeing this issue have it happen reliably, it would be invaluable for you to add the following to Help>Diagnostic Tools>Debug Log Settings (the leading
#
s are important):#com.illuminatedcloud.util.CommandLineUtil #com.illuminatedcloud.intellij.sfdx.SfdxUtil #com.illuminatedcloud.util.VariableLengthPollingInterval #com.illuminatedcloud.intellij.settings.application.IlluminatedCloudConnectionConfig
and then to reproduce the issue several times, then either attach your
idea.log
(Help>Show Log in Explorer/Finder/Files) or email it to support@illuminatedcloud.com for review. As always, feel free to redact sensitive information, but please leave the overall JSON structure intact as that's what I'll be examining.I'll post any additional updates here as this is my sole focus until I figure out what's going on and can provide a reliable fix.
-
repo owner One more request for those of you having this issue. Can you please have IC force refresh its connection cache to see if that resolves the issue? You can do so using the following button:
If you do that, please let me know whether it helps or not.
-
repo owner Okay, I have an update. I have successfully reproduced this issue, but not reliably. Here's what I did to reproduce it:
- From the command-line, created several scratch orgs without aliases. I don't know if the lack of an alias is part of the issue, but since some of the comments on this thread have indicated a lack of consistent aliases as a potential contributor, I followed that pattern.
- Once those were created, I refreshed IC's connection list which explicitly runs
sfdx force:org:list --json
and received the errorCannot read property 'SignupUsername' of undefined
. This is the same error observed by Cesar. Salesforce is aware of this and will be issuing a CLI update tomorrow (Thursday) with the fix. The net effect of this would be--you guessed it--no SFDX-based connections in the IC connection list. - I then refreshed IC's connection list again and all was well, so that error is not consistent. Forcing IC's connection list to refresh seems to be a viable workaround, as is downgrading to 48.10.1 temporarily.
Hopefully this is the core issue that's plaguing people and tomorrow's CLI update will address it. If it doesn't, it's going to be critical that I receive debug logs from when this problem occurs on the updated version so I can understand what's happening. I'm also going to make sure that a reported error like this is actually presented properly to the end user in IC as right now it just looks like it succeeded but didn't get any connections from the CLI.
As always, more to come as it emerges, but for now hopefully this helps explain what's going on--at least in part--and provides a few options for workarounds until the issue is fully resolved.
-
repo owner Note that I have just posted 2.1.1.9 that better handles failure of
sfdx force:org:list
execution. Now the error message is properly displayed to the end user via a notification and the response is not cached. In my test--which is admittedly limited due to difficulty reproducing--it seems that forcing the connection list to refresh as described two comments above resolves the issue. Hopefully tomorrow's Salesforce CLI update will put this to rest entirely. -
repo owner The CLI update was just posted:
48.13.1 (May 7, 2020)
FIX: The force:org:list command no longer throws unexpected errors.
Everyone having this issue, please run
sfdx update
to receive the new version and let me know if you continue to see these issues. Hopefully this will put it to rest, but if it doesn't then at least it should clear one issue off the table so I/we can focus on whatever is left.I'll be interested to know your experience after updating either way.
-
Account Deactivated Update seems to have worked for me (still on IC 2.1.1.8)
-
repo owner Thanks for confirming, Cesar. And to clarify, you were seeing this problem consistently enough that you feel that it seems to be fixed now?
-
Account Deactivated That's right! I never got it to work even with the force refresh before this 😅 (except for downgrading)
-
repo owner Well that's certainly a good sign! Of course, let me know if things get weird for you again, and feedback from others is encouraged so I can get a better sense of where things are after this CLI update.
-
reporter Updated to IC 2.1.118 and cli 48.13.1. It seems that it works without problem so far.
-
repo owner That's great to hear, Kostas. Thanks! Fingers crossed that this is it, but I won't resolve this issue until sometime next week to ensure there's more burn-in time on the new CLI build.
-
reporter Thanks Scott for your effort!
-
repo owner Oh, man...thanks to everyone here for the patience and understanding as well as the willingness to provide useful diagnostic info, and of course to the Salesforce CLI team for listening and turning around a fix so quickly!
-
I just upgraded to 2.1.1.9 and lost all my OAuth connections. The only thing that changed was I downloaded the plugin update, restarted the IDE, and Boom. All the OAuth are gone. Unless there is something I can share to help diagnose, I’m reverting.
-
OK, that was weird. The root cause of my problem was that the IC ‘Salesforce DX executable’ was empty. I repopulated, restarted IDEA, and I am back in business.
-
repo owner Jeff, also make sure that you've updated the Salesforce CLI to today's build. That's the source of the regression that caused this issue. You'll want both fully-updated.
-
repo owner Quick update...we're not totally out of the woods yet. This morning I reproduced the issue with some orgs not being listed with aliases properly by
force:org:list
. Luckily I was able to capture a debug log showing the exact command-line invocations and have sent this to the team at Salesforce.In my case this happened when the orgs were listed immediately following creation of a new scratch org. The scratch org was created with an alias but the next
force:org:list
only included the following:{ "username": "test-ned0pvucfgt6@example.com", "orgId": "00D1g000000EJyLEAW", "accessToken": "redacted", "refreshToken": "redacted", "instanceUrl": "https://app-dream-5064-dev-ed.cs96.my.salesforce.com/", "loginUrl": "https://CS96.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS96", "created": "1588950410143", "devHubUsername": "redacted", "expirationDate": "2020-06-07", "status": "Active", "isExpired": false }
I clicked IC's connection list Refresh button to force it to run
force:org:list
again, and that execution included all of the expected info:{ "username": "test-ned0pvucfgt6@example.com", "orgId": "00D1g000000EJyLEAW", "accessToken": "redacted", "instanceUrl": "https://app-dream-5064-dev-ed.cs96.my.salesforce.com/", "loginUrl": "https://CS96.salesforce.com", "clientId": "PlatformCLI", "createdOrgInstance": "CS96", "created": "1588950410143", "devHubUsername": "redacted", "expirationDate": "2020-06-07", "alias": "LWC_Recipes", "lastUsed": "2020-05-08T15:07:00.586Z", "status": "Active", "isExpired": false, "signupUsername": "test-ned0pvucfgt6@example.com", "createdBy": "redacted", "createdDate": "2020-05-08T15:06:43.000+0000", "devHubOrgId": "00D37000000Hl6WEAS", "attributes": { "type": "ScratchOrgInfo", "url": "/services/data/v48.0/sobjects/ScratchOrgInfo/2SR1G0000004CjkWAE" }, "orgName": "LWC Recipes", "edition": "Developer", "connectedStatus": "Unknown" }
So there's definitely still some issue here, and it seems to be introduced very recently as I never saw this behavior before the past week or so. If you see this errant behavior, the workaround is to refresh the connection list one more time. Again, I've reported this to Salesforce already so hopefully a fix will be issued quickly. I'm also going to check on my side to see if there's anything I can do to provide a more automated workaround.
-
repo owner And one more update. I can reproduce this consistently by running the following even directly from the CLI:
sfdx force:org:create ... -a <alias> ... sfdx force:org:list # The output of this one looks like the first snippet above with no alias sfdx force:org:list # The output of this one looks correct, i.e., like the second snipped above
I've provided those steps including a full execution log from the CLI to the Salesforce CLI team. Hopefully they'll be able to turn around a fix quickly, but as stated above, if you see this behavior, just click the connection list refresh button and it should fix itself...until the next time you create a new org.
-
repo owner And yet another update. I just saw this happen completely outside any context of a
force:org:create
. IC ran aforce:org:list
to get information about the SFDX connections and one of the scratch orgs I created two weeks or so back was reported with no alias. When I refreshed the connection list, all was good again. So basically if you see this happen, you'll need to force IC to refresh its connection list. Hopefully Salesforce will provide a fix for this quickly. -
reporter I think latest version of sfdx has more issues. Scratch orgs are shown under Org list and not under scratch orgs.
Notice that the first is a scratch org.
-
repo owner Kostas, it's almost certainly a symptom of the same issue. As you can see above, when this problem occurs
force:org:list
doesn't include the full set of information about the org, then on the next listing it does. My guess is that in your case it's not correctly reporting that as a scratch org. Please see if force refreshing the list doesn't remedy the issue, and hopefully Salesforce will turn around a fix for this aspect quickly. -
reporter Scott, the problem is in sfdx cli. sfdx force:org:list lists scratch org in Org list and not in scratch org list. It is not a IC problem. I have created an issue https://github.com/forcedotcom/cli
-
repo owner That's right, Kostas. I know that last week's build of the CLI required heavy refactoring. The fact that a few regressions did creep through isn't entirely surprising, and Salesforce has already fixed the first one we identified. Hopefully this one will be addressed in the coming week's build. Thanks for filing that issue to help raise the visibility!
-
repo owner It does not appear that this week's CLI build addresses the remaining issues that have been discussed here and in
#1615. I'll keep working with Salesforce to try to figure out what's going on and keep everyone posted here. For the time being, the same workarounds apply. -
reporter Yes, I confirm the same thing. We also see multiple users of the same scratch org (but it is not a new bug).
-
repo owner Issue
#1621was marked as a duplicate of this issue. -
repo owner The Salesforce CLI was updated today, reportedly with fixes for many (most? all?) of these issues. If you are not on a specific build of the CLI, please use
sfdx update
to install the latest. If you have temporarily reverted to a stable previous build, please usesfdx plugins:uninstall salesforcedx
followed bysfdx plugins:install salesforcedx
to move back onto the latest.Once you are on this week's build or higher, please force Illuminated Cloud to refresh its connection list using the Refresh toolbar button in Illuminated Cloud>Configure Application>Connections, then let me know if you see any of these issues recur. Hopefully it's all addressed, but if it's not I can convey details to Salesforce in pursuit of a complete fix.
-
repo owner - changed status to resolved
I'm resolving this now since it appears that it has been successfully fixed in the CLI based on the few weeks' usage.
- Log in to comment
Note that I have just posted 2.1.1.9 that better handles failure of
sfdx force:org:list
execution. Now the error message is properly displayed to the end user via a notification and the response is not cached. In my test--which is admittedly limited due to difficulty reproducing--it seems that forcing the connection list to refresh as described two comments above resolves the issue. Hopefully tomorrow's Salesforce CLI update will put this to rest entirely.