Message 'wantsToRetrieveCustomFields' is inaccurate.

[goto-dev-null]

Summary

First off, tracing this back to its commit & PR, this is not -as it was labeled- "Warning a user". This is adding functionality that completely changes how the plugin works, and a warning to go with it. It's a breaking change. I know this because it broke for us and starting pulling hundreds of changes it did not before.

But getting onto the issue, the message is just plain wrong and that didn't help to narrow down the problem:

"Because you're retrieving one or more CustomFields, we're also retrieving the CustomObject to which it's associated."

The code itself specifies that if it's the wildcard, not "one or more CustomFields". It should say exactly that: "If you specify '*' for CustomField, it will pull all objects", because as it stands, I can manually specify as many fields as I want on Account and not get that error.

Steps To Reproduce:

Manifest including: <types> <name>CustomField</name> <members>*</members> </types> vs <types> <name>CustomField</name> <members>Account.MyCustomField__c</members> </types>

Expected result

Error message saying exactly which tag (since in this case it is specifically and only ever 1) is causing the issue, i.e. wildcard.

Actual result

Bad error message that isn't consistent with behavior (a la scenario 2 above)

System Information

{ "cliVersion": "sfdx-cli/7.131.0", "architecture": "linux-x64", "nodeVersion": "node-v17.3.0" }

Additional Information

I'm very curious as to why such a large change was made seemingly without thought as to the implications. My hunch is that it's attempting to fix the fact that CustomObject's child metadata are tightly coupled to the CustomObject so the solution is to just always pull the CustomObject, but that's not a small change that should just be made. And now it makes the manifest fairly useless since wildcards in one tag can effect contents of another tag. Why even have a manifest if it's going to do whatever it wants?

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

[mshanemc]

Thank you for the feedback.

That warning was intended to solve the confusion around force:source:retrieve -m CustomField which the metadata api doesn't support (without the object, it returns an empty but "successful" result). Would your warning rewrite make sense to a user that's using -m ?

This issue report does have me curious as to what your manifest is intending that you wanted preserved? When I use this, nothing happens. What did you intend by using a * for CustomField without any objects?

<types>
  <name>CustomField</name>
  <members>*</members>
</types>

The logic behind this change was, "Well, that command/manifest doesn't do anything at all, but people think it does/should so we're going to try to make it do what it seems like it should do (and would do for every other metadata type except CustomField)"

[goto-dev-null]

I still hold that the warning doesn't make sense with -m as it is now.

If I run -m CustomField, I am told "Because you're retrieving one or more CustomFields..." If I run -m CustomField:Account.MyCustomField__c, I am not despite me retrieving one or more CustomField If this only shows when using a wildcard (implicit or explicit) then it should say so. It's not "one or more CustomFields", it's an indeterminate number of fields.

My phrasing specifically calling out the '*' isn't applicable for -m but the idea it's getting at is still correct: it's when you are specifically saying 'pull all the things, however many there are', not 'one or more'.

The answer to your question is that this we have been unsure as to how SFDX retrieves an Object's child metadata. For example, if you only specify -m RecordType, it will strip out all PickList values because you are not also pulling that field. So in every place possible in the manifest for child Metadata of Object, we try to include a wildcard. Exceptions would be what we manually have to inject into the manifest, notably for us, Custom Fields on packaged or standard objects are not detected by the wildcard. Our understanding (and maybe this is wrong or was right and is now wrong) is that the wildcard would pull non-packaged fields.

I actually just made a task recently for coming back and reevaluating what we're retrieving, if it's being done correctly, and what elements we also might be able to deploy through our normal processes that we are not presently. I guess the question that would be relevant here is, how are we meant to specify all custom fields in an org that are not packaged in a manifest, or would we have to manually construct it?

Thanks for the response!

[git2gus[bot]]

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

[mshanemc]

I've slightly tweaked the message, and also check to make sure that the message doesn't appear for the scenario where's you've

• not used a wildcard
• specified the field(s)

[jshackell-sfdc]

This issue was fixed in version 2.47.6 (June 26, 2024).