Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

force:alias:set command exits successfully but doesn't do anything when there's another (in this case stale) entry with that alias in .sfdx/alias.json #1810

Closed
SCWells72 opened this issue Nov 16, 2022 · 4 comments
Labels
bug Issue or pull request that identifies or fixes a bug investigating We're actively investigating this issue

Comments

@SCWells72
Copy link

I'd noticed recently that force:alias:set didn't seem to working reliably and decided to troubleshoot it a bit today in an effort to characterize the behavior before logging an issue here. I think I've cornered it now. Here's what I've found...

First, I ran the following (output scrubbed for only the relevant subset):

$ sfdx force:org:list
WARNING: You have 55 expired or deleted local scratch org authorizations. To remove authorizations for inactive orgs, run force:org:list --clean.
=== Orgs

   ALIAS                                USERNAME                      ORG ID             EXPIRATION DATE
 ─ ──────────────────────────────────── ───────────────────────────── ────────────────── ───────────────
   NPSP_-_Dev_Workspace_-_Multicurrency [email protected] 00D8H0000004drwUAA 2022-12-16
$ sfdx force:alias:set [email protected] --json
{
  "status": 0,
  "result": [
    {
      "alias": "npsp_sf_no_ns",
      "value": "[email protected]"
    }
  ]
}
$ sfdx force:org:list
WARNING: You have 55 expired or deleted local scratch org authorizations. To remove authorizations for inactive orgs, run force:org:list --clean.
=== Orgs

   ALIAS                                USERNAME                      ORG ID             EXPIRATION DATE
 ─ ──────────────────────────────────── ───────────────────────────── ────────────────── ───────────────
   NPSP_-_Dev_Workspace_-_Multicurrency [email protected] 00D8H0000004drwUAA 2022-12-16

As you can see, force:alias:set reported success, but the actual update didn't seem to occur, at least not in terms of how the alias/username associations in the output of force:org:list.

I looked at .sfdx/alias.json and noticed that there was already an entry with alias npsp_sf_no_ns for an expired scratch org, so I thought that perhaps running force:org:list --clean might help clear that stale entry and others. After running that command, I was seeing the same behavior, and I also saw the same stale entries in alias.json. I then manually removed the entry for npsp_sf_no_ns from alias.json, re-ran force:alias:set, and the alias was properly associated with the new username.

So there seem to be two potential issues here, one perhaps benign and one that seems to break force:alias:set in certain situations. The former is that I would have expected force:org:list --clean to remove not just the stale org entries but also their corresponding entries in alias.json. The latter is that when an alias is already set in alias.json, it seems that it cannot be "moved" to another org's username.

Oh, and I haven't confirmed this, but another thought just popped into my mind...perhaps the username for that alias was in fact updated, but the original alias wasn't removed and is still being picked up making the behavior more around which entry was found first in the list?

This all on the following CLI version (probably should have started there):

$ sfdx version
sfdx-cli/7.176.1 win32-x64 node-v18.12.0
@SCWells72 SCWells72 added the investigating We're actively investigating this issue label Nov 16, 2022
@github-actions
Copy link

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.

@peternhale peternhale added the bug Issue or pull request that identifies or fixes a bug label Nov 16, 2022
@git2gus
Copy link

git2gus bot commented Nov 16, 2022

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

@mshanemc
Copy link
Contributor

mshanemc commented Jun 8, 2023

@SCWells72 there was a problem with the alias file not handling concurrency well. list --clean does remove aliases, but it wasn't doing it very well.

That's fixed by #1806 in https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#72056-june-15-2023-stable-rc

@mshanemc
Copy link
Contributor

mshanemc commented Jun 8, 2023

I've tried using alias:set to set different orgs to the alias...seems to work.

Note: org list will only show one alias, so if you have several aliases to the same org, it might look like the newer ones aren't changing, but they are in the alias.json file.

This issue will close next week when the fix gets into latest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue or pull request that identifies or fixes a bug investigating We're actively investigating this issue
Projects
None yet
Development

No branches or pull requests

3 participants