Metadata API request failed: request to https://../services/Soap/m/##.0 failed, reason: getaddrinfo EAI_AGAIN

[mcarvin8]

I've seen this bug since switching to the sf CLI, including the most recent build. It happens randomly and isn't reproducible. Seen while running sf project deploy start and sf project deploy validate commands.

I understand EAI_AGAIN is a DNS issue, but I've seen previous CLI bugs such as the "Org Cannot Be Found" error be temporarily resolved by disabling the DNS check with the environment variable. SF_DISABLE_DNS_CHECK=true

I am running the CLI in a GitLab CI/CD environment with Kubernetes (K8s) runners and the latest Ubuntu container.

My question is where specifically in the code base is this error raised? Does this occur when the CLI determines the latest API version available in the Org? Will disabling the DNS check resolve this issue and is there any downsides to disabling the DNS? If I keep the maximum API version stored in the sfdx-project.json file in my VCS, I don't see the need for the additional API version check done by the DNS.

Please let me know what I can do to hopefully remove this Metadata API failure.

Steps To Reproduce

Cannot re-produce this type of bug.

Seen while running these commands:
sf project deploy start for deploy (non-apex)
sf project deploy validate for validations ahead of quick-deploys (apex)
sf project deploy quick for quick-deploys (apex)

Expected result

CLI final status matches the Salesforce Deployment Status.

Actual result

Pipelines using the CLI occasionally fail with this error as the deployment continues in the Salesforce Org.

System Information

Bash / Ubuntu Docker Image (latest) / GitLab CI/CD with Kubernetes runners

We build our Custom Docker Image using this Dockerfile:

We have also seen this while using alpine:latest before we switched to Ubuntu.

FROM ubuntu:latest

# Set Salesforce CLI Environment Variables
ENV SF_AUTOUPDATE_DISABLE=true \
    # ^-- By default, the CLI periodically checks for and installs updates.
    #     Disable (false) this auto-update check to improve performance of CLI commands.
    SF_USE_GENERIC_UNIX_KEYCHAIN=true \
    # ^-- Set to true if you want to use the generic UNIX keychain instead of the Linux libsecret library or macOS keychain.
    #     Specify this variable when using the CLI with ssh or "headless" in a CI environment.
    SF_DOMAIN_RETRY=300 \
    # ^-- Specifies the time, in seconds, that the CLI waits for the Lightning Experience custom domain to resolve and become available in a newly-created scratch org.
    #     If you get errors about My Domain not configured when you try to use a newly-created scratch org, increase this wait time.
    SF_PROJECT_AUTOUPDATE_DISABLE_FOR_PACKAGE_CREATE=true \
    # ^-- For force:package:create, disables automatic updates to the sfdx-project.json file.
    SF_PROJECT_AUTOUPDATE_DISABLE_FOR_PACKAGE_VERSION_CREATE=true \
    # ^-- For force:package:version:create, disables automatic updates to the sfdx-project.json file.
    SF_DISABLE_DNS_CHECK=true
    # ^-- Disable the DNS check done when looking for the latest API version in the org.

# Install python3, nodejs, npm, Salesforce CLI, and output versions
RUN apt-get update && apt-get install -y curl python3 && \
    curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - && \
    apt-get install -y nodejs && \
    npm install --global @salesforce/[email protected] && \
    sf version --verbose --json

{
  "cliVersion": "@salesforce/cli/2.10.2",
  "architecture": "linux-x64",
  "nodeVersion": "node-v18.17.1",
  "osVersion": "Linux 5.15.108",
  "shell": "bash",
  "rootPath": "/usr/lib/node_modules/@salesforce/cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.8 (core)",
    "@oclif/plugin-commands 2.2.25 (core)",
    "@oclif/plugin-help 5.2.19 (core)",
    "@oclif/plugin-not-found 2.4.1 (core)",
    "@oclif/plugin-plugins 3.7.1 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.2.3 (core)",
    "@oclif/plugin-version 1.3.10 (core)",
    "@oclif/plugin-warn-if-update-available 2.1.0 (core)",
    "@oclif/plugin-which 2.2.32 (core)",
    "@salesforce/cli 2.10.2 (core)",
    "apex 2.3.15 (core)",
    "auth 2.8.17 (core)",
    "data 2.5.9 (core)",
    "deploy-retrieve 1.18.0 (core)",
    "info 2.6.43 (core)",
    "limits 2.3.34 (core)",
    "login 1.2.31 (core)",
    "marketplace 0.2.2 (core)",
    "org 2.10.8 (core)",
    "schema 2.3.26 (core)",
    "settings 1.4.29 (core)",
    "sobject 0.2.7 (core)",
    "source 2.10.34 (core)",
    "telemetry 2.3.3 (core)",
    "templates 55.5.12 (core)",
    "trust 2.6.13 (core)",
    "user 2.3.32 (core)"
  ]
}

Additional information

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

[Tarun-streamforcesolutions]

Hello Team,
While pushing to sandbox for review through CLI we are getting below mentioned error .
Support pointed us towards here saying this is a CLI issue and not associated with deployment error.

Metadata API request failed: request to https://xyz--review.sandbox.my.salesforce.com/services/Soap/m/60.0 failed, reason: getaddrinfo EAI_AGAI

cc: @mcarvin8

[mcarvin8]

I still see this failure all the time in our CI pipelines and locally. I closed this because I went back and forth with the team who maintains our Kubernetes runners for my work's CI infrastructure and Salesforce support.

These Metadata API request failures are pretty frequent in any environment (CI and local) and I'm starting to see metadata api requests failures without any error statement like EAI_AGAIN.

Feel free to raise this issue but I threw in the towel after the back and forth.

It would be nice if the CLI had more of a retry limit for network failures like this, if that isn't a feature already. Some other community members have mentioned they set the wait time to 0 seconds for deployments to return to the terminal, then periodically check the deployment status every X minutes.

I have a local script that builds Deploy ID links back to Salesforce when the ID is made, so I usually track deployments in Salesforce when these metadata api request failures occur. #2531