CLI commands do not properly stub ~/.sfdx when missing during command execution on Mac; Windows/Linux are fine

[SCWells72]

A Mac user reported an issue to me where, in IC2, things could go haywire if the ~/.sfdx directory is missing when IC2 executes force:org:list (and potentially other commands). I was unable to reproduce that behavior...but evidently because I was trying to do so specifically on Windows, though Linux looks fine as well. Here's the behavior across various platforms:

Mac M1 (fails):

$ mv ~/.sfdx ~/_sfdx
$ mv ~/.sf ~/_sf
$ sfdx org list --json
{
  "code": 1,
  "context": "OrgListCommand",
  "commandName": "OrgListCommand",
  "message": "ENOENT: no such file or directory, scandir '/Users/swells/.sfdx'",
  "name": "Error",
  "status": 1,
  "stack": "Error: ENOENT: no such file or directory, scandir '/Users/swells/.sfdx'",
  "exitCode": 1,
  "warnings": []
}

Ubuntu Linux (works):

$ mv ~/.sfdx ~/_sfdx
$ mv ~/.sf ~/_sf
$ sfdx org list --json
{
  "status": 0,
  "result": {
    "nonScratchOrgs": [],
    "scratchOrgs": []
  },
  "warnings": []
}

Windows (works):

$ mv ~/.sfdx ~/_sfdx
$ mv ~/.sf ~/_sf
$ sfdx org list --json
{
  "status": 0,
  "result": {
    "nonScratchOrgs": [],
    "scratchOrgs": []
  },
  "warnings": []
}

I'm assuming that in all cases, the command should stub the ~/.sfdx directory and not blow up like this, no?

[github-actions]

Hello @SCWells72 👋 It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[SCWells72]

Note that it's important to delete/move both ~/.sfdx and ~/.sf or you can get issues with log rotation, e.g.:

$ mv ~/.sfdx ~/_sfdx
$ sfdx org list --json
[Error: ENOENT: no such file or directory, rename '/home/swells/.sf/sf.log.0' -> '/home/swells/.sf/sf.log.1'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'rename',
  path: '/home/swells/.sf/sf.log.0',
  dest: '/home/swells/.sf/sf.log.1'
}
[Error: ENOENT: no such file or directory, rename '/home/swells/.sf/sf.log.0' -> '/home/swells/.sf/sf.log.1'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'rename',
  path: '/home/swells/.sf/sf.log.0',
  dest: '/home/swells/.sf/sf.log.1'
}
{
  "status": 0,
  "result": {
    "nonScratchOrgs": [],
    "scratchOrgs": []
  },
  "warnings": []
}

While still an error, that's already logged elsewhere, e.g., #2209.

[SCWells72]

CLI versions on the respective OSes:

Windows:

$ sfdx version
sfdx-cli/7.204.6 win32-x64 node-v18.15.0

Linux:

$ sfdx version
sfdx-cli/7.204.6 linux-x64 node-v19.9.0

Mac:

$ sfdx version
sfdx-cli/7.204.6 darwin-x64 node-v18.15.0

[iowillhoit]

Hey Scott 👋 This should be working as expected in latest (sfdx-cli/7.205.6), can you please have them update and try again?

Sidenote: I do think there is a check we can add to prevent this from happening again

[SCWells72]

Looks better to me after updating:

$ sfdx version
sfdx-cli/7.205.6 darwin-x64 node-v18.15.0
$ mv ~/.sfdx ~/_sfdx
$ mv ~/.sf ~/_sf
$ sfdx org list --json
{
  "status": 0,
  "result": {
    "nonScratchOrgs": [],
    "scratchOrgs": []
  },
  "warnings": []
}

I'll ask the user to update and verify as well. I'm curious...was this already slated for the latest update, or did you squeeze it in at the last minute?

[iowillhoit]

The timing of the fix actually appears to be completely unrelated. The problem was coming from here. When the .sfdx directory did not exist, it would throw an error.

@mshanemc recently make some changes to aliases (PR) and that included a check to ensure the aliases file existed (and the .sfdx directory as well).

Based on telemetry, we are also seeing some org:list errors on Linux and Windows as well. Not entirely sure why they were not seeing the same issue.

[SCWells72]

Ah, so the "fix" was actually just serendipity. Any idea why the original problem was unique to Mac and not present on Windows/Linux? And if I'm wandering too far into the weeds, feel free to say so. Just curious, but to some extent, a fix is a fix.

[git2gus]

This issue has been linked to a new work item: W-13602928

[iowillhoit]

I am honestly not sure Scott, we have telemetry that is also showing errors for Linux and Windows on the org:list command in the last 24 hours. Could have been how the CLI is being installed, for example using yarn to install the CLI would not respect the shrinkwrap file and pull in the most recent sfdx-core 🤷

[iowillhoit]

Whoops, this should have been closed a while ago. I added a check to prevent this from becoming a regression later on.