Failed deployments using MDAPI don't output failure details

[daveespo]

Summary

Certain types of deployment failures are just reported back to the user as "Failed" with no further detail. A specific example is a deployment failure due to lack of a dependency package version.

It seems like all flavors of project deploy are affected (ex. --metadata ApexClass, -x package.xml and just a straight project deploy start using source tracking

Steps To Reproduce:

• Create a project that has a dependency on a specific managed package (i.e. an Apex class that has a dependency on global Apex from a managed package)
• Create a new scratch org and install the dependency package
• Deploy your source that depends on the dependency package version that's installed
• Edit your Apex class's meta-xml so that it depends on a newer version of the managed package than the one that's installed. For example, if you previously depended on 57.6 and now depend on 57.9, edit your meta.xml so it looks like

<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>54.0</apiVersion>
    <packageVersions>
        <majorNumber>57</majorNumber>
        <minorNumber>9</minorNumber>
        <namespace>PatronPay</namespace>
    </packageVersions>
    <status>Active</status>
</ApexClass>

Then attempt to deploy your changes -- the example below use a package.xml deployment but the same result occurs if you use a project deploy start

esposito@PT-WIN-ESPOSITO:~/patrontrx$ sfdx project deploy start -x manifest/package.xml
*** Deploying v54.0 metadata with SOAP API v57.0 connection ***
Deploy ID: 0Af8N00000XwK4mSAF
Status: Failed | ████████████████████████████████████████ | 268/268 Components

esposito@PT-WIN-ESPOSITO:~/patrontrx$ echo $?
1
esposito@PT-WIN-ESPOSITO:~/patrontrx$

Here's the same with a straight source-tracked push:

esposito@PT-WIN-ESPOSITO:~/patrontrx$ sfdx project deploy start  --ignore-conflicts
*** Deploying v54.0 metadata with SOAP API v57.0 connection ***
Deploy ID: 0Af8N00000XwQHmSAN
Status: Failed | ████████████████████████████████████████ | 3/3 Components

esposito@PT-WIN-ESPOSITO:~/patrontrx$ echo $?
1
esposito@PT-WIN-ESPOSITO:~/patrontrx$

If you run with the --json flag, you do get output:

esposito@PT-WIN-ESPOSITO:~/patrontrx$ sfdx project deploy start  --ignore-conflicts --json
{
  "status": 1,
  "result": {
    "checkOnly": false,
    "completedDate": "2023-05-17T12:19:10.000Z",
    "createdBy": "0058N0000035mvJ",
    "createdByName": "[email protected] PatronTrx",
    "createdDate": "2023-05-17T12:19:06.000Z",
    "details": {
      "componentFailures": [
        {
          "changed": false,
          "componentType": "ApexClass",
          "created": false,
          "createdDate": "2023-05-17T12:19:06.000Z",
          "deleted": false,
          "fileName": "classes/PaymentMethodControllerExt.cls-meta.xml",
          "fullName": "classes/PaymentMethodControllerExt.cls-meta.xml",
          "problem": "The specified Package Version number does not exist for that Package: PatronPay, 57.9",
          "problemType": "Error",
          "success": false
        }
....

Expected result

I expected the root cause to be displayed: "The specified Package Version number does not exist for that Package: PatronPay, 57.9"

Actual result

CLI reports "Failed" with no further detail

System Information

{
  "cliVersion": "sfdx-cli/7.200.7",
  "architecture": "wsl-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Linux 5.10.102.1-microsoft-standard-WSL2",
  "shell": "bash",
  "rootPath": "/home/esposito/.local/share/sfdx/client/7.200.7-499d9c2",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.1.9 (core)",
    "@oclif/plugin-commands 2.2.14 (core)",
    "@oclif/plugin-help 5.2.9 (core)",
    "@oclif/plugin-not-found 2.3.23 (core)",
    "@oclif/plugin-plugins 3.0.1 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.13 (core)",
    "@oclif/plugin-version 1.3.3 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.36 (core)",
    "@oclif/plugin-which 2.2.19 (core)",
    "apex 2.2.15 (core)",
    "auth 2.7.14 (core)",
    "community 2.2.11 (core)",
    "custom-metadata 2.1.19 (core)",
    "data 2.3.14 (core)",
    "deploy-retrieve 1.8.18 (core)",
    "info 2.6.10 (core)",
    "limits 2.3.13 (core)",
    "org 2.8.1 (core)",
    "packaging 1.16.11 (core)",
    "schema 2.3.10 (core)",
    "settings 1.4.6 (core)",
    "signups 1.4.14 (core)",
    "source 2.10.7 (core)",
    "telemetry 2.2.0 (core)",
    "templates 55.4.13 (core)",
    "trust 2.4.14 (core)",
    "user 2.3.10 (core)",
    "sfdx-cli 7.200.7 (core)"
  ]
}

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

[mshanemc]

nice repro, thank you!

[git2gus]

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

[daveespo]

Willie asked me to re-test this and I can confirm that it is fixed in deploy-retrieve 1.11.3

Status: Failed | ████████████████████████████████████████ | 1/1 Components
Deploying v54.0 metadata to [email protected] using the v58.0 SOAP API.
Component Failures [1]rAk2CAE
=======================================================================================================================
| Type  Name                                            Problem
| ───── ─────────────────────────────────────────────── ───────────────────────────────────────────────────────────────
| Error classes/PaymentMethodControllerExt.cls-meta.xml The specified Package Version number does not exist for that P…

As the above demonstrates, it runs afoul of the bug reported in #2048 and the output is truncated .. but at least there's a clue as to what's going on there. I'm closing out this issue and will wait patiently on #2048 :-)