Increased reliability on poor network connections/interruptions

[dxenonb]

Is your feature request related to a problem? Please describe.

When network connection is interrupted, pushing to a scratch org fails and the only recourse is pushing again (5+ minutes each failure). On large pushes, this is incredibly frustrating, and I expect it to be frustrating for anyone on a poor internet connection.

In my case I am working on a Dell XPS running Windows at home - I am both far from the router and working on a Dell XPS (which I wouldn't say is reliable by any measure!). Probably applies to anyone working in areas with less internet infra or working from public WiFi.

What are you trying to do

Push to a scratch org

Describe the solution you'd like

In case of network interruption, the metadata API/sfdx tooling should be more resilient, retrying and resuming deployment without requiring a full push.

Describe alternatives you've considered

/edit:

Non-ideal Work around: on the deployment details page you can check the status of the deployment. It may actually succeed but you have no way to get that info from the CLI without starting a new deployment. Recovering from network interruptions would be a great improvement to the workflow still.

/end edit

Retrying over and over again 😢. Minimizing network traffic. Smaller deployments would be ideal but are a large development lift in my case. We could also build our own tooling. Using Salesforce packaging could be an option but introduces other performance/scratch org complexity issues.

Additional context

If I intentionally disconnect from WiFi during a push, I can reproduce this error. The error message:

Job ID | [job id]
SOURCE PROGRESS | ████████████████████████████████████████ | 4062/4063 ComponentsERROR:  Error: getaddrinfo ENOTFOUND [org url].my.salesforce.com
Unhandled rejection Error: getaddrinfo ENOTFOUND [org url].cs4.my.salesforce.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26)

N.b., updated my DX CLI version:
7.66.2-4f159a1d07 to 7.68.6-d37008df83

And the error still occurs.

[Techley-git]

Same issue trying to push a deployment to production

I have to 'terminate batch' (ctrl +c) to get my command line responsive again.

PS path\goes\here> sfdx force:mdapi:deploy -w -1 -d metadataPackage_1603227010263 -l RunSpecifiedTests -r  testnames       
Job ID | [jobid]
MDAPI PROGRESS | ████████████████████████████████████████ | 2/2 ComponentsERROR:  Error: getaddrinfo ENOTFOUND [org-url].my.salesforce.com
Unhandled rejection Error: getaddrinfo ENOTFOUND [org-url].my.salesforce.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:66:26)
^CTerminate batch job (Y/N)? y

To work around the issue I go find my deployment details on the deployment status page by jobID.

[dxenonb]

To work around the issue I go find my deployment details on the deployment status page by jobID.

Updated the OP with this! Saves frustration when you need it, but I wasn't aware of the feature at the time, and the workflow is still very non-ideal.

[Techley-git]

Aye, its something I found by accident. Perhaps a feature gap of SFDX is we can't do a friendly name on our deployments so I'm having to populate job IDs in our records since we do a mix of change sets (Which do allow for user entry/names).

That's how I found the job ID shows in deployment history.

[pawel-id]

Such issue is happening also on our CI pipelines when deploying to scratch orgs

sample command: sfdx force:source:deploy -p force-app -u SCRATCH
sfdx-cli version: 7.86.3

and sample output:

Job ID | 0Af1X00001PDfgMSAT
SOURCE PROGRESS | ████████████████████████████████████████ | 0/0 Components
SOURCE PROGRESS | ████████████████████████████████████████ | 0/0 Components
SOURCE PROGRESS | ████████████████████████████████████████ | 0/0 Components
SOURCE PROGRESS | ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 0/2258 Components
SOURCE PROGRESS | ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 0/2258 Components
SOURCE PROGRESS | ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 94/2258 Components
SOURCE PROGRESS | ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 94/2258 Components
ERROR:  Error: read ECONNRESET
Unhandled rejection Error: read ECONNRESET
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)
SOURCE PROGRESS | ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 94/2258 Components

another sample:

SOURCE PROGRESS | ████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 684/2258 Components
ERROR:  Error: connect ETIMEDOUT 85.222.144.159:443
Unhandled rejection Error: connect ETIMEDOUT 85.222.144.159:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
SOURCE PROGRESS | ████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 684/2258 Components

after such error the process never completes.

It is happening roughy estimate 10% of all deployments.