IC2 does not correctly present deployment failures in all cases

Issue #2261 resolved
Phil W created an issue

Our scenario is that we have an existing LWC deployed to the org. This has a single targetConfig covering a number of different targets, including lightning__FlowScreen, lightning__AppPage, lightning_HomePage and lightning__RecordPage.

On changing the LWC’s meta configuration to split out the lightning__FlowScreen into its own separate targetConfig (with or without changes to the declared property list for that targetConfig) we deploy the LWC. IC2 indicates success. However, Salesforce deployment status tells a different story:

When observing the deployment status information during the attempt to update the LWC we noticed that as the deployment ends it briefly transitions to success then immediately switches to showing the fatal error.

The error we see is similar to (but not the same as) that described over here on SFSE. For us we can successfully deploy the updated LWC as long as we first delete it from the scratch org.

Note that we use sfdx force:source:push via the “push” toolbar button to perform the deployment.

Comments (5)

  1. Scott Wells repo owner

    The Salesforce CLI can be a bit inconsistent in how it reports errors in its JSON output. It’s much better now than it was in the early days, but there are still one-offs where errors get stuffed into unexpected locations. It’d be great if you could enable debug logging for both Metadata Deployment and Salesforce DX, reproduce this issue, and attach enough of the idea.log so that I can see the JSON output of the force:source:push command invocation. That will show me how this error is being reported so that I can update IC2’s processing of that output accordingly.

  2. Scott Wells repo owner

    Phil, I see one execution of force:source:push, and it’s not designated as a failure, specifically:

    2022-11-18 09:56:31,875 [  64993]   FINE - #c.i.i.b.ForceComSfdxDeployer - Received push response:
    {
      "status": 0,
      "successResponse": {
        "status": 0,
        "result": {
          "pushedSource": [
            {
              "filePath": "C:\\Users\\some-user\\IdeaProjects\\some-project\\force-app\\main\\default\\lwc\\autoAssign\\autoAssign.css",
              "fullName": "autoAssign",
              "state": "Changed",
              "type": "LightningComponentBundle"
            },
            {
              "filePath": "C:\\Users\\some-user\\IdeaProjects\\some-project\\force-app\\main\\default\\lwc\\autoAssign\\autoAssign.html",
              "fullName": "autoAssign",
              "state": "Changed",
              "type": "LightningComponentBundle"
            },
            {
              "filePath": "C:\\Users\\some-user\\IdeaProjects\\some-project\\force-app\\main\\default\\lwc\\autoAssign\\autoAssign.js",
              "fullName": "autoAssign",
              "state": "Changed",
              "type": "LightningComponentBundle"
            },
            {
              "filePath": "C:\\Users\\some-user\\IdeaProjects\\some-project\\force-app\\main\\default\\lwc\\autoAssign\\autoAssign.js-meta.xml",
              "fullName": "autoAssign",
              "state": "Changed",
              "type": "LightningComponentBundle"
            }
          ]
        }
      }
    }
    

    If that did result in an actual failed deployment on the server, the issue is likely in the Salesforce CLI and should be reported in their issue tracker after reproducing the same behavior by running sfdx force:source:push directly from the command-line. Otherwise if this wasn't a good reproduction of the issue, please see if you can capture a log from a proper reproduction and attach that log for review.

  3. Scott Wells repo owner

    Anything to report here, Phil? Have you been able to confirm whether this is a CLI issue or not? Not sure if I should resolve this from an IC2 perspective or keep it open.

  4. Scott Wells repo owner

    I'm going to go ahead and resolve it here, but if you find that the same behavior doesn't occur outside of IC2, please reopen with additional diagnostic info.

  5. Log in to comment