Auth'ing a Scratch org before any other org causes it to be a "Non-scratch org"

[cromwellryan]

Summary

If a scratch org is auth'ed (via auth url) as the very first Org, it will appear as a Non-Scratch org (in org list). Even after auth'ing other non-scratch orgs.

Steps To Reproduce

1. Create a scratch org: [email protected]
2. Capture it's auth url: sfdx org display --target-org [email protected] --verbose --json | jq -r .result.sfdxAuthUrl > auth.file
3. Log out of all orgs: sfdx org logout --all
4. Auth the scratch org: sfdx org login sfdx-url --sfdx-url-file auth.file -d -s --alias my-scratch-org
5. (optional) Auth a known, non-scratch org: sfdx org login web

Expected: Org shows as a Scratch Org
Actual: Org shows as a Non-Scratch Org

System Information

{
  "cliVersion": "sfdx-cli/7.208.10",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v20.3.1",
  "osVersion": "Darwin 22.5.0",
  "shell": "zsh",
  "rootPath": "/Users/rcromwell/.nvm/versions/node/v20.3.1/lib/node_modules/sfdx-cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.1 (core)",
    "@oclif/plugin-commands 2.2.16 (core)",
    "@oclif/plugin-help 5.2.10 (core)",
    "@oclif/plugin-not-found 2.3.26 (core)",
    "@oclif/plugin-plugins 3.1.5 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.21 (core)",
    "@oclif/plugin-version 1.3.5 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.40 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "apex 2.3.3 (core)",
    "auth 2.8.4 (core)",
    "community 2.3.3 (core)",
    "custom-metadata 2.1.28 (core)",
    "data 2.4.2 (core)",
    "deploy-retrieve 1.13.3 (core)",
    "info 2.6.24 (core)",
    "limits 2.3.22 (core)",
    "org 2.9.17 (core)",
    "packaging 1.20.1 (core)",
    "schema 2.3.15 (core)",
    "settings 1.4.15 (core)",
    "signups 1.4.22 (core)",
    "source 2.10.19 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.5.0 (core)",
    "trust 2.4.24 (core)",
    "user 2.3.19 (core)",
    "sfdx-cli 7.208.10 (core)"
  ]
}

[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.

[AllanOricil]

@cromwellryan repeat your tests adding an custom expiration date when creating this SO. After reading the following lines of code my guess is that the default expiration date isn't stored in the local cache when creating the first SO.

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/org.ts#L670-L687

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/org.ts#L563-L577

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/org.ts#L620-L635

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/org.ts#L666-L687

[AllanOricil]

Maybe this would actually happen with all SOs added using the auth url? Could you add 2 SOs in sequence and verify that both aren't considered SOs.
My guess is that the expiration date, which is used to determine if it is or not a SO, isn't fetched when authing using sfdx auth url

[shetzel]

That's an atypical flow. Scratch orgs rely on devhubs since that's the only way they are created so the auth is pretty tightly coupled with devhub orgs. Your flow would work if you authed (or re-authed) to the devhub org before re-authing to the scratch org because of this code: https://github.com/forcedotcom/sfdx-core/blob/main/src/org/authInfo.ts#L389
Unfortunately, we can't just ask an org if it's a scratch org or sandbox; we have to detect it. The more information we have, the more reliably we can detect it. Expiration date is not very reliable, but if we ask all the authed devhubs about the org and one of them "knows about" it we can safely consider it a scratch org.

We can look into improving detection when the auth file already exists but until then I would auth to the devhub before the scratch org and that should allow your flow to work.

[AllanOricil]

That's an atypical flow. Scratch orgs rely on devhubs since that's the only way they are created so the auth is pretty tightly coupled with devhub orgs. Your flow would work if you authed (or re-authed) to the devhub org before re-authing to the scratch org because of this code: https://github.com/forcedotcom/sfdx-core/blob/main/src/org/authInfo.ts#L389
Unfortunately, we can't just ask an org if it's a scratch org or sandbox; we have to detect it. The more information we have, the more reliably we can detect it. Expiration date is not very reliable, but if we ask all the authed devhubs about the org and one of them "knows about" it we can safely consider it a scratch org.

We can look into improving detection when the auth file already exists but until then I would auth to the devhub before the scratch org and that should allow your flow to work.

Some folks on stackoverflow say it is possible to use the tooling api to query the TrialExpirationDate and IsSandbox fields from the Organization object to determine if it is a SO or not. Maybe u could do it before saving the new org when its devhub isn't authed yet.

https://salesforce.stackexchange.com/questions/256499/how-can-i-determine-if-the-org-that-im-currently-connected-to-is-a-scratch-org

[AllanOricil]

Or u could maybe add isScratchOrg to the exported sfdx authurl?

[cristiand391]

note: [with enhanced domains turned on] the instance url of a scratch org ends with scratch.my.salesforce.com, we could try a few approaches like this and what Allan suggests.

[shetzel]

We can check these things as part of detection but they tend to be unreliable and change without warning, especially URLs. Without the devhub auth file there will almost certainly be problems with other commands too, like trying to delete that scratch org or doing most packaging commands.

[AllanOricil]

export the whole org information as base64. The person who created the org will for sure have the information if it is or not a SO, because the type is specified as an input when creating it.

I'm suggesting you to change the sfdx auth url to be a base64 to make it easier for us to pipe the exported data into sfdx auth in the future, as I suggested here

echo $exported_org | sfdx auth

flags could overwrite the information contained within the decoded base64 so that developers could change, for example, the alias of the newly imported org.

You could even allow people to include the DevHub info in this exported base64. This way devs can import both at the same time with a single command. This can be achieved with an additional flag under the export command.

To export the org, you could maybe create a new commands under auth|org called import and export:

sfdx auth:export -k $secret or sfdx org:export -k $secret

echo $exported_org | sfdx auth:import -k $secret or echo $exported_org | sfdx org:import -k $secret

you could also add an optional key flag which allows people to encrypt the exported org information.

[mshanemc]

I've looked at a couple ways to do this (ex: when you auth to a new org that is a devHub, ask it if it knows if any non-scratch orgs might actually be its children) and the juice:squeeze ratio is off given

1. what an edge case this is
2. how easy it is to re-auth the scratch org, which results in the correct answer

Eventually, when we get enhancedDomains on by default for scratch orgs like they are for sandboxes and it becomes more obvious by its instanceUrl, then we could do something smarter.

[AllanOricil]

Im going to fix this and earn my oscar

and the oscar goes to...
a guy from the country side of broken country who solved an issue that saved millions of minutes around the world
tears drop
the crowd goes wild afterwards
everyone salutes him