Cli: Unhandled Rejection returns exit code 0

[jamesmelville]

Summary

sfdx force:source:push failed with the error

Unhandled rejection Error: connect ETIMEDOUT 161.71.2.159:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1126:14)

yet it still returned exit code 0, indicating success. I expect it to raise an error (return non 0 exit code) so that my CI job would fail on this step and highlight it to me.

Steps To Reproduce:

Unsure, maybe disconnect network during push?

Expected result

Should have returned an exit code != 0 so that command was marked as failed

Actual result

Exit code 0 returned

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version):
sfdx-cli/7.28.7 linux-x64 node-v12.11.1
SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)

@oclif/plugin-commands 1.2.3 (core)
@oclif/plugin-help 2.2.1 (core)
@oclif/plugin-not-found 1.2.3 (core)
@oclif/plugin-plugins 1.7.8 (core)
@oclif/plugin-update 1.3.9 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.0.5 (core)
analytics 1.2.1 (core)
generator 1.1.1 (core)
salesforcedx 47.1.5 (core)
├─ force-language-services 47.5.0 (core)
└─ salesforce-alm 47.4.0 (core)

sfdx-cli 7.28.7 (core)

OS and version:
https://github.com/salestrip/docker-sfdx-cli/blob/master/Dockerfile

[clairebianchi]

@jamesmelville thank you, we will take a look, we through a 1 on error, so its odd that you are seeing 0 that is a problem.

[girasedinesh]

Hi All,
I am facing same issue while executing below command
sfdx force:source:deploy --checkonly -x manifest/package.xml --targetusername $SF_USERNAME --wait 120 --testlevel RunLocalTests --verbose

I have raised this issue here - https://github.com/nodejs/help/issues/3071

sfdx plugins --core
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
config 1.1.9 (core)
generator 1.1.3 (core)
salesforcedx 50.1.1 (core)
├─ apex 0.1.1 (core)
├─ templates 50.1.0 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
├─ salesforce-alm 50.1.1 (core)
└─ custom-metadata 1.0.10 (core)
sfdx-cli 7.76.1 (core)

[trentchilders]

I'm getting this error when trying to build to a scratch org, running sfdx force:source:push
Error:

Unhandled rejection Error: connect ETIMEDOUT 136.147.101.223:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)

@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.3 (core)
analytics 1.12.1 (core)
auth 1.3.0 (core)
config 1.1.11 (core)
generator 1.1.3 (core)
salesforcedx 50.5.0 (core)
├─ custom-metadata 1.0.10 (core)
├─ schema 1.0.1 (core)
├─ templates 50.1.0 (core)
├─ salesforce-alm 50.5.0 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
└─ apex 0.1.2 (core)
sfdx-cli 7.80.0 (core)

[laithal]

I'm seeing the same issue as well

sfdx-cli latest

sfdx force:source:push -f
Job ID | 0Af1X000016eKf2SAE

ERROR: Error: connect ETIMEDOUT 85.222.147.31:443
Unhandled rejection Error: connect ETIMEDOUT 85.222.147.31:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)

[murthytumuluri04]

I am see ting same issue while building a package with manifest

Unhandled rejection Error: connect ETIMEDOUT 13.110.30.13:443 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16) 20:16:29.377 sfdx force:source:retrieve --manifest

[amphro]

We can't reproduce. Can anyone get a stacktrack by chance? You can try --dev-debug but since this is unhandled it may not work. You could try to put the following in any file that is being loaded during the cli process.

process.on('unhandledRejection', (reason, p) => {
  console.log(reson.stack);
});

[jamesmelville]

Thanks for looking into this. TBH I'm not sure if I've seen the same scenario that I initially reported since then (it's been a while!).

But I just tried ripping the upstream ethernet cable from my switch during a push, and it displayed the below error, but then never exited, just sat there with a flashing cursor. I reconnected the cable, but no new output suggested it was still polling, so I pressed Ctrl-C after a few minutes.

C:\Users\james\Workspace>sfdx force:source:push -u ScratchOrg --dev-debug
//logs
Job ID | 0Af7E00001QlEYlSAN
SOURCE PROGRESS | █████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 468/2027 ComponentsERROR:  Error: connect ETIMEDOUT 161.71.10.32:443
Unhandled rejection Error: connect ETIMEDOUT 161.71.10.32:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)
From previous event:
    at processImmediate (internal/timers.js:456:21)
From previous event:
    at Force.mdapiCheckDeployStatus (C:\Users\james\AppData\Local\sfdx\node_modules\salesforce-alm\dist\lib\core\force.js:610:53)
    at CheckStatus._getStatus (C:\Users\james\AppData\Local\sfdx\node_modules\salesforce-alm\dist\lib\mdapi\mdapiCheckStatusApi.js:89:21)
    at CheckStatus._pollForStatus (C:\Users\james\AppData\Local\sfdx\node_modules\salesforce-alm\dist\lib\mdapi\mdapiCheckStatusApi.js:56:14)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)

Similarly ripping the cable directly from the computer resulted in ECONNABORTED instead of ETIMEDOUT with the same stack trace, as you might expect.

This behaviour isn't ideal either, but also I'm probably not effectively reproducing what happened before.

• I can't say that I ripped the cable in the same phase of the push. (and seems people are reporting similar issues with other commands which go out over the internet)
• I'm running the latest version of sfdx-cli 7.82.0, so it might well have changed in the interim
• I'm also testing from my windows machine as unplugging the cable on my docker instance in the cloud is a bit harder.