Error: Could not infer a metadata type when running `project retrieve start`

[parkerbrown11]

Note Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

When I run the project retrieve start on a new CustomField, the error message in the Actual Result section below occurs. I recently updated sf cli to the latest version. The /decomposed folder in our project contains broken down profile and permission set metadata.

Steps To Reproduce

IMPORTANT Provide a repository that's configured to reproduce the issue. If you are unable to provide a repo, please explain why not. The more info we have from the start, the faster we can resolve your issue. We may close your issue if you don't include proper instructions.

• Generate a project with sf project generate or fork dreamhouse-lwc.
• Provide detailed step-by-step instructions on how to reproduce the issue.

1. run this command:
   • sf project retrieve start -m CustomField:pse__Project_Task__c.Product_SKU__c

Expected result

Clean retrieve of the new custom field into project source

Actual result

Error (1): /Users/parkerbrown11/Documents/repos/salesforce/force-app/main/default/permissionsets/decomposed/AD_Credentials_Management/AD_Credentials_Management.xml: Could not infer a metadata type

Try this:

A metadata type lookup for "AD_Credentials_Management.xml" found the following close matches:
-- Did you mean ".xml" instead for the "EmailServicesFunction" metadata type?

Additional suggestions:
Confirm the file name, extension, and directory names are correct. Validate against the registry at:
<https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json>

If the type is not listed in the registry, check that it has Metadata API support via the Metadata Coverage Report:
<https://developer.salesforce.com/docs/metadata-coverage>

If the type is available via Metadata API but not in the registry

- Open an issue <https://github.com/forcedotcom/cli/issues>
- Add the type via PR. Instructions: <https://github.com/forcedotcom/source-deploy-retrieve/blob/main/contributing/metadata.md>

System Information

using zsh

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.46.6",
  "nodeVersion": "node-v18.12.1",
  "osVersion": "Darwin 23.5.0",
  "rootPath": "/Users/parkerbrown11/.nvm/versions/node/v18.12.1/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@jayree/sfdx-plugin-prettier 1.3.66 (user) published 9 days ago (Sat Jun 15 2024) (latest is 1.3.68)",
    "@oclif/plugin-autocomplete 3.1.2 (core)",
    "@oclif/plugin-commands 4.0.2 (core)",
    "@oclif/plugin-help 6.2.1 (core)",
    "@oclif/plugin-not-found 3.2.3 (core)",
    "@oclif/plugin-plugins 5.2.4 (core)",
    "@oclif/plugin-search 1.1.2 (core)",
    "@oclif/plugin-update 4.3.5 (core)",
    "@oclif/plugin-version 2.2.3 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.5 (core)",
    "@oclif/plugin-which 3.2.2 (core)",
    "@rdietrick/sfdx-profile-decompose 1.0.2 (user) published 619 days ago (Fri Oct 14 2022)",
    "@salesforce/cli 2.46.6 (core)",
    "apex 3.1.18 (core)",
    "auth 3.6.21 (core)",
    "data 3.4.6 (core)",
    "deploy-retrieve 3.9.4 (core)",
    "info 3.3.6 (core)",
    "limits 3.3.12 (core)",
    "marketplace 1.2.12 (core)",
    "org 4.2.1 (core)",
    "packaging 2.4.6 (core)",
    "schema 3.3.11 (core)",
    "settings 2.3.1 (core)",
    "sobject 1.4.11 (core)",
    "source 3.4.2 (core)",
    "telemetry 3.4.0 (core)",
    "templates 56.2.11 (core)",
    "trust 3.7.5 (core)",
    "user 3.5.13 (core)",
    "prodlysfcli 1.1.0 (user) published 94 days ago (Fri Mar 22 2024)",
    "sfdx-deliverability-access 1.2.0 (user) published 556 days ago (Fri Dec 16 2022)"
  ]
}

Additional information

[github-actions[bot]]

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.

[shetzel]

How was that decomposed folder created? What are the contents of your sfdx-project.json file?

[parkerbrown11]

Hi @shetzel thanks for the quick reply.

The decomposed folder is created for this custom plugin: @rdietrick/sfdx-profile-decompose 1.0.2 Specifically, when you run this command, the profile and permission set files are split into separate but organized files for easier maintenance. They are held under the decomposed folder.

The full contents of the sfdx-project.json file

  "name": "ghsf",
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "name": "ghsf",
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "60.0",
  "plugins": {
    "sfdx-plugin-prettier": {
      "enabled": true
    }
  }
}

[shetzel]

I've never used that plugin, but based on the plugin docs you would need to run the aggregate command before any sf project deploy/retrieve command. That plugin changes the metadata on the local file system in a way that is not understood by the core CLI plugins and will cause problems like you're seeing.

You can continue using that plugin and its commands and dealing with decompose/aggregate and the source tracking issues that can occur, or you can use the new "source behavior" features recently added to the core CLI plugins that handle these things for you. I don't believe Profiles are one of the metadata types supported by the "source behavior" feature though.

Reference these release notes: https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md#2448-jun-5-2024 Reference this discussion: https://github.com/forcedotcom/cli/discussions/2544

Please reopen if this does not solve your issue.

[parkerbrown11]

Yes, I've been using that plugin for some time now and my retrieves have been working great up until I upgraded to the @salesforce/cli latest from 2.27.6 the other day. Since that upgrade it's been giving the error.

When I go back to @salesforce/cli version 2.27.6 it does a retrieve successfully without having to aggregate first with the decompose plugin. Is there something that changed with the way the retrieve command works between 2.27.6 and the latest?

[shetzel]

Is there something that changed with the way the retrieve command works between 2.27.6 and the latest?

Possibly, but that file structure shouldn't work with any CLI version. Not sure why it wasn't throwing the same error with 2.27.6 but that plugin manipulates metadata in a way that the core CLI plugin (deploy-retrieve) can't work with unless (per the docs) you run that aggregate command.

We can look into it a bit further, but the answer will likely be the same.

[parkerbrown11]

Yes, when we run a retrieve on our full project, we have to run the aggregate command before it is successful, even with the 2.27.6 CLI version. If I'm retrieving a single CustomField file with the below command, unrelated to any profiles or permission sets, it works with the 2.27.6 version even without running the aggregate command. It doesn't work with the latest version of the sf CLI.

Does that change things at all from your end? Or would the answer still be the same?

sf project retrieve start -m CustomField:pse__Project_Task__c.Product_SKU__c

[WillieRuemmele]

Hey @parkerbrown11 -

I'm surprised this was working in previous versions given that the file is in the project, have you been able to narrow down it down to what version of the CLI this behavior began in? That would be very useful

have you looked at adding these files to your .forceignore - There's a chance that will cause this directory/file to be skipped now

[parkerbrown11]

Hi @WillieRuemmele I'll try to narrow things down to the exact version when this behavior began and let you know. I'll also try out adding the files to the .forceignore