sfdx force:source:deploy and sfdx force:mdapi:deploy return 0 when deployment is timed out

[MuriloKakazu]

Summary

It seems that the deploy commands for both source and mdapi return 0 when the deployment times out.

Steps To Reproduce:

given that multiple machines are running tests or deploying to a sandbox env at the same time:

sfdx force:source:deploy --checkonly --wait 60 --testlevel RunLocalTests --sourcepath ./src

Expected result

It should not return 0 since the deployment timed out

Actual result

If the deploy times out, echo $? returns 0

Additional information

I'm migrating a CI/CD pipeline from using Ant to SFDX, and with Ant it used to fail the workflow if the deployment timed out, which sounds like a reasonable expected result

SFDX CLI Version:
sfdx-cli/7.63.0 darwin-x64 node-v14.2.0

SFDX plugin Version:
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.2.3 (core)
@oclif/plugin-help 3.0.1 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.7.10 (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.0.7 (core)
analytics 1.9.1 (core)
generator 1.1.3 (core)
salesforcedx 48.19.0 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.5 (core)
├─ salesforce-alm 48.20.0 (core)
├─ salesforcedx-templates 48.18.0 (core)
└─ custom-metadata 1.0.4 (core)
sfdx-cli 7.63.0 (core)

OS and version:
macOS Catalina 10.15.5

[MuriloKakazu]

I'm now using linux's timeout command for the expected behavior as a work around, ensuring sfdx does not return 0 before the system times it out:

timeout 60m sfdx force:source:deploy --wait 62 ...

But I still believe SFDX is not working as expected and should be fixed because it does not sound reasonable to consider a timeout as a success at all...

[uip-robot-zz]

This issue has been linked to a new work item: W-9299038

[mshanemc]

cf W-6835454.

[mshanemc]

This is still a problem for mdapi deployments, but is fixed in the new source plugin (see the link/announcement above).

So we'll call that a pending, partial fix of the bug.

[amtrack]

@mshanemc Good to see that this has been fixed for the source commands! 🙏

Can you maybe give an estimate when we can expect this to be fixed for all the mdapi commands as well?

I'm forced to use the mdapi:deploy to be able to handle destructive changes for example.

As a workaround, I'm now initiating the deployment using mdapi with --wait 0
and then using the report command of the new source command.

Example:

deployId="$(sfdx force:mdapi:deploy --deploydir src --checkonly --wait 0 --json \
  | tee /dev/stderr | node -pe 'JSON.parse(fs.readFileSync(0, "utf8")).result.id')"
sfdx force:source:deploy:report -i "${deployId}" --wait 60

Note: I'm explicitly specifying the deployment id to not conflict with any other deployment here.

This seems to work, but do you maybe know if there might be cases where this workaround won't work?