[BUG]: API version cache never hits under a non-US locale: `instanceApiVersionLastRetrieved` is written with `toLocaleString()` and read with `Date.parse`, so every command runs the My Domain DNS check

Il report identifica Connection.retrieveMaxApiVersion() e getCachedApiVersion() come percorsi di scrittura e lettura; inizia individuando questi metodi e i relativi test nel CLI o nel codice sorgente del core incluso. Verifica come viene scritto e analizzato il timestamp, quindi aggiungi test per una locale diversa da quella degli Stati Uniti. Il lavoro è completato quando la cache della versione dell’API rimane valida per 24 ore tra locale diverse e i comandi ripetuti evitano la ricerca DNS aggiuntiva.

Before You Submit

• I'm using the latest version of Salesforce CLI
• I've searched the existing issues
• I've run sf doctor to diagnose common issues

Related Issue

#3425 (the same API-version re-check path, for an org a command does not need; fixed in 2.123.1)

Command

any command that uses an org, e.g. sf data query -o <alias> -q "SELECT Id FROM Organization"

Org Type

Scratch Org

Did this work before?

Not sure

Last Working Version

No response

Summary

Connection.retrieveMaxApiVersion() caches the org's API version in the auth file with instanceApiVersionLastRetrieved: new Date().toLocaleString(), and getCachedApiVersion() reads that back with Date.parse(). toLocaleString() follows the process locale, and Date.parse() reads US-style dates. Under LANG=en_GB.UTF-8 the date is written 25/10/2026, 20:58:29, which parses to NaN, so the cache never hits.

So every command fetches the API version again, and first runs the My Domain DNS check (isResolvable() → MyDomainResolver, 3 s by default). One slow DNS answer then fails the command with DomainNotFoundError: The org cannot be found, though the org is fine: it stopped a three-hour test harness that makes an sf call about every ten seconds.

On the 1st to the 12th of a month, the same string parses with day and month swapped. Written on 10 May (10/05/2026), it reads as 5 October: in the future, so the cache does not expire for months. Written on 5 October (05/10/2026), it reads as 10 May, so it is always stale.

Repository to Reproduce

none needed: the root cause needs only node, and the effect any authenticated org.

Steps to reproduce

1. The root cause, no org:

   LANG=en_GB.UTF-8 node -e "const s=new Date(2026,9,25,20,58,29).toLocaleString(); console.log(s, Date.parse(s))"
   # 25/10/2026, 20:58:29 NaN
   LANG=en_GB.UTF-8 node -e "const s=new Date(2026,4,10,9,0,0).toLocaleString(); console.log(s, new Date(Date.parse(s)).toISOString())"
   # 10/05/2026, 09:00:00 2026-10-05T…   (10 May read as 5 October)
   

2. The effect, with an org: run the same command twice per locale with debug logging. After each command, count the Attempting to resolve url lines the day's log gained:

   L=~/.sf/sf-$(date +%Y-%m-%d).log
   for loc in en_GB.UTF-8 en_GB.UTF-8 en_US.UTF-8 en_US.UTF-8 en_GB.UTF-8 en_GB.UTF-8; do
     b=$(grep -c "Attempting to resolve url" $L)
     LANG=$loc SF_LOG_LEVEL=debug sf data query -o <alias> -q "SELECT Id FROM Organization" --json > /dev/null
     echo "$loc $(( $(grep -c "Attempting to resolve url" $L) - b )) lookups; cache: $(jq -r .instanceApiVersionLastRetrieved ~/.sfdx/<username>.json)"
   done
   

Expected Result

After the first command, the API version comes from the cache for 24 hours, whatever the locale, and no DNS check runs.

Actual Result

Measured 2026-10-25 on 2.155.7 with the loop above, against a scratch org:

en_GB.UTF-8 2 lookups; cache: 25/10/2026, 23:24:04
en_GB.UTF-8 2 lookups; cache: 25/10/2026, 23:24:06
en_US.UTF-8 1 lookups; cache: 10/25/2026, 11:24:07 PM
en_US.UTF-8 0 lookups; cache: 10/25/2026, 11:24:07 PM
en_GB.UTF-8 0 lookups; cache: 10/25/2026, 11:24:07 PM
en_GB.UTF-8 0 lookups; cache: 10/25/2026, 11:24:07 PM

Under en_GB, every command looks the org up twice and rewrites the cache date. Once an en-US date is written, en_GB reads it, until the 24 hours run out and the date is written in GB form again.

Error Message

What one slow DNS answer does to a command that runs the check. Here the slow answer is simulated: a --require hook delays dns.lookup of the org's host by 5 s, and SFDX_IGNORE_API_VERSION_CACHE=true makes the check run as the locale bug does. The real slow answer, on 2.138.6, stopped an sf project deploy start with the same error.

$ SFDX_IGNORE_API_VERSION_CACHE=true sf data query -o <alias> -q "SELECT Id FROM Organization"
Error (DomainNotFoundError): Parsing --target-org
	The org cannot be found

Workaround: SFDX_DNS_TIMEOUT=30 (the same call: exit 0 after 22 s, the record returned). Not SF_DNS_TIMEOUT, which does nothing: see Additional Information.

System Information

{
  "architecture": "linux-x64",
  "cliVersion": "@salesforce/cli/2.155.7",
  "nodeVersion": "node-v24.14.0",
  "osVersion": "Linux 6.8.0-93260105-generic",
  "rootPath": "<cut>",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 4.0.4 (core)",
    "@oclif/plugin-commands 5.0.4 (core)",
    "@oclif/plugin-help 7.0.4 (core)",
    "@oclif/plugin-not-found 4.0.4 (core)",
    "@oclif/plugin-plugins 7.0.7 (core)",
    "@oclif/plugin-search 2.0.0 (core)",
    "@oclif/plugin-update 5.0.4 (core)",
    "@oclif/plugin-version 3.0.5 (core)",
    "@oclif/plugin-warn-if-update-available 4.0.3 (core)",
    "@oclif/plugin-which 4.0.4 (core)",
    "@salesforce/cli 2.155.7 (core)",
    "agent 2.2.2 (core)",
    "apex 4.4.3 (core)",
    "api 2.0.17 (core)",
    "auth 5.0.16 (core)",
    "data 5.1.16 (core)",
    "deploy-retrieve 4.2.14 (core)",
    "info 4.0.16 (core)",
    "limits 4.0.6 (core)",
    "marketplace 2.0.17 (core)",
    "org 6.0.26 (core)",
    "packaging 3.0.14 (core)",
    "schema 4.0.12 (core)",
    "settings 3.0.14 (core)",
    "sobject 2.0.12 (core)",
    "telemetry 4.2.0 (core)",
    "templates 57.4.6 (core)",
    "trust 4.0.20 (core)",
    "user 5.0.11 (core)"
  ]
}

Additional Information

• Suggested fix: write the date as new Date().toISOString(). Date.parse() reads ISO 8601 in every locale. A date already written in the old form is replaced the next time it reads as stale, but one that parsed into the future holds until that date.
• SF_DNS_TIMEOUT is ignored. Setting SFDX_DNS_TIMEOUT makes sf warn "Deprecated environment variable: SFDX_DNS_TIMEOUT. Please use SF_DNS_TIMEOUT instead.", but src/status/myDomainResolver.ts reads only new Env().getNumber('SFDX_DNS_TIMEOUT', 3). With SF_DNS_TIMEOUT=30 and no SFDX_DNS_TIMEOUT, the Error Message call above fails at 7.3 s, as with neither set. Measured on 2.155.7 and 2.138.6. So following the warning puts the timeout back to 3 s, and nothing says so.
• Node's default locale (ICU) follows LC_ALL, then LC_MESSAGES, then LANG. LC_TIME alone does not change it. Not measured on macOS or Windows.
• Ubuntu 24.04.3 LTS, bash, LANG=en_GB.UTF-8. Bundled @salesforce/core 9.3.6. Also seen on 2.138.6 (core 8.31.0). Also seen against a production Dev Hub, not only scratch orgs.

Screenshots or Log Files

No response