forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
486 stars 78 forks source link

Destructive Changes are failing without a reason #1203

Closed MGarfOppLoans closed 2 years ago

MGarfOppLoans commented 2 years ago

Summary

When issuing a destructive change of any kind (just code, just permission sets) we are seeing it fail without a stated reason. This just started happening at random and is causing all our ci/cd pipelines to fail. This is happening across 10 environments in through branch groups each with their own destructive changes with different combination of metadata. Running with local copy successfully deletes it

Steps To Reproduce:

Run sfdx force:source:delete -m "PermissionSet:View_All_Data_System_Permission,PermissionSet:Quick_Text_Admin" -r --json

Expected result

{
  "status": 0,
  "result": {
    "deletedSource": []
  }
}

Actual result

{
    "status": 1,
    "result": {
      "deletedSource": [],
      "outboundFiles": [],
      "deletes": [
        {}
      ]
    }
  }

System Information

Running in Github Actions on image: salesforce/salesforcedx:latest-full

Run sfdx version --verbose --json and paste the output here.

{
    "cliVersion": "sfdx-cli/7.119.2",
    "architecture": "linux-x64",
    "nodeVersion": "node-v14.17.1",
    "pluginVersions": [
        "@oclif/plugin-autocomplete 0.3.0 (core)",
        "@oclif/plugin-commands 1.3.0 (core)",
        "@oclif/plugin-help 3.2.3 (core)",
        "@oclif/plugin-not-found 1.2.4 (core)",
        "@oclif/plugin-plugins 1.10.1 (core)",
        "@oclif/plugin-update 1.5.0 (core)",
        "@oclif/plugin-warn-if-update-available 1.7.0 (core)",
        "@oclif/plugin-which 1.0.3 (core)",
        "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
        "alias 1.1.10 (core)",
        "apex 0.2.8 (core)",
        "auth 1.7.1 (core)",
        "config 1.2.35 (core)",
        "custom-metadata 1.0.12 (core)",
        "data 0.6.1 (core)",
        "generator 1.2.0 (core)",
        "limits 1.2.1 (core)",
        "org 1.7.0 (core)",
        "salesforce-alm 52.3.5 (core)",
        "schema 1.0.8 (core)",
        "sfdx-cli 7.119.2 (core)",
        "source 1.1.0 (core)",
        "telemetry 1.2.4 (core)",
        "templates 52.1.0 (core)",
        "trust 1.0.8 (core)",
        "user 1.4.0 (core)"
    ],
    "osVersion": "Linux 5.8.0-1041-azure"
}
github-actions[bot] commented 2 years ago

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.

uip-robot-zz commented 2 years ago

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

mshanemc commented 2 years ago

Yeah, I see how you got that one...deleting something from the org that doesn't exist in the local project, right?

MGarfOppLoans commented 2 years ago

Nah, we actually do a source retrieve before the delete to avoid that exact issue funny enough because that caused issues in the past

MGarfOppLoans commented 2 years ago

Essentially our process is.

  1. Read from YAML file containing all destructive changes:
- PermissionSet:Quick_Text_Admin
- PermissionSet:View_All_Data_System_Permission

Do a retrieve of all metadata in the list.

Anything retrieved is then added to a destructive list (we ignore what doesn't get pulled down)

Then do a delete

MGarfOppLoans commented 2 years ago

Found the issue. The retrieve response changed, thank you you led me in the right direction

retrieveResult.result {
    inboundFiles: [
      {
        fullName: 'View_All_Data_System_Permission',
        type: 'PermissionSet',
        state: 'Failed',
        error: "Entity of type 'PermissionSet' named 'View_All_Data_System_Permission' cannot be found",
        problemType: 'Error'
      },
      {
        fullName: 'Quick_Text_Admin',
        type: 'PermissionSet',
        state: 'Failed',
        error: "Entity of type 'PermissionSet' named 'Quick_Text_Admin' cannot be found",
        problemType: 'Error'
      }
    ],
    packages: [],
    warnings: [
      {
        fileName: 'unpackaged/package.xml',
        problem: "Entity of type 'PermissionSet' named 'View_All_Data_System_Permission' cannot be found"
      },
      {
        fileName: 'unpackaged/package.xml',
        problem: "Entity of type 'PermissionSet' named 'Quick_Text_Admin' cannot be found"
      }
    ],
    response: {
      done: true,
      fileProperties: [ [Object] ],
      id: '09S2V000002123pUAA',
      messages: [ [Object], [Object] ],
      status: 'Succeeded',
      success: true
    }
  }
mshanemc commented 2 years ago

What's causing your retrieve to fail? Something with the CLI, or something else?

[I'm still keeping this as a bug because you should be able to delete stuff from the org even if it doesn't exist locally]

MGarfOppLoans commented 2 years ago

Huge fan of that, will speed up our builds if we don't have to retrieve first.

Based on the snippet it seems it failed to retrieve those items because they aren't in the org. Historically it would just silently not pull them but some recent change to the CLI now has it returning which caused our builds to break since we assumed any items returned were the ones in the org

iowillhoit commented 2 years ago

This has been fixed and released in 7.122.1. See release notes here