-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: Could not infer a metadata type when running project retrieve start
#2940
Comments
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. |
How was that decomposed folder created? What are the contents of your sfdx-project.json file? |
Hi @shetzel thanks for the quick reply. The decomposed folder is created for this custom plugin: @rdietrick/sfdx-profile-decompose 1.0.2 The full contents of the sfdx-project.json file
|
I've never used that plugin, but based on the plugin docs you would need to run the aggregate command before any 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 Please reopen if this does not solve your issue. |
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? |
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 ( We can look into it a bit further, but the answer will likely be the same. |
Yes, when we run a Does that change things at all from your end? Or would the answer still be the same?
|
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 |
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 |
This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted. |
Still planning to perform previous tasks soon. |
This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted. |
Maybe a .forceignore file is involved here |
Summary
When I run the
project retrieve start
on a new CustomField, the error message in theActual 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
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
System Information
using zsh
Additional information
The text was updated successfully, but these errors were encountered: