sf project retrieve start -m 'CustomObject:*' silently fails to retrieve standard objects.

[codefriar]

Summary

Calling sf project retrieve start -m CustomObject or sf project retrieve start "CustomObject:*" both fail to retrieve standard objects - without warning or error. This is ... counter intuitive, to say the least.

Steps To Reproduce

Execute: sf project retrieve start -m CustomObject or sf project retrieve start "CustomObject:*"

Any repository will work with this issue.

Expected result

EITHER:

1. All objects, including standard objects, are retrieved. ie: foo__c and Account
2. Only custom objects are retrieved, but output explaining this behavior is given to the user. Note, while this would at least explain the issue, in reality, I want / need -m CustomObject to retrieve standard and custom objects. I'm kind of at a loss as to why it wouldn't.

I am aware that I can create a pacakge.xml file to do this retrieve. What I don't understand is ... why -m CustomObject doesn't function as ... well, I expect. In our present use case, writing a package.xml isn't exactly a ... convenient option. it will result in 2 retrieve calls happening.

Actual result

Only custom objects and custom metadata objects are retrieved.

Additional information

System Information

Mac os Sonoma 14.6.1, with ZSH

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.58.7",
  "nodeVersion": "node-v20.17.0",
  "osVersion": "Darwin 23.6.0",
  "rootPath": "/Users/kevinpoorman/.volta/tools/image/packages/@salesforce/cli/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.2 (core)",
    "@oclif/plugin-commands 4.0.13 (core)",
    "@oclif/plugin-help 6.2.10 (core)",
    "@oclif/plugin-not-found 3.2.18 (core)",
    "@oclif/plugin-plugins 5.4.6 (core)",
    "@oclif/plugin-search 1.2.7 (core)",
    "@oclif/plugin-update 4.5.5 (core)",
    "@oclif/plugin-version 2.2.11 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.13 (core)",
    "@oclif/plugin-which 3.2.12 (core)",
    "@salesforce/cli 2.58.7 (core)",
    "apex 3.4.8 (core)",
    "api 1.2.1 (core)",
    "auth 3.6.54 (core)",
    "data 3.6.5 (core)",
    "deploy-retrieve 3.12.3 (core)",
    "dev 2.4.2 (user) published 25 days ago (Mon Aug 26 2024)",
    "info 3.4.3 (core)",
    "limits 3.3.29 (core)",
    "marketplace 1.2.25 (core)",
    "org 4.5.7 (core)",
    "packaging 2.8.2 (core)",
    "schema 3.3.26 (core)",
    "settings 2.3.16 (core)",
    "sobject 1.4.33 (core)",
    "source 3.5.18 (core)",
    "telemetry 3.6.10 (core)",
    "templates 56.3.17 (core)",
    "trust 3.7.27 (core)",
    "user 3.5.29 (core)",
    "@salesforce/sfdx-scanner 4.5.0 (user) published 25 days ago (Tue Aug 27 2024)",
    "bah-toolkit 1.0.0 (link) /Users/kevinpoorman/src/bah-toolkit"
  ]
}

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

[WillieRuemmele]

Hey @codefriar - this is really a limitation of the metadata API ☹️ - from https://developer.salesforce.com/docs/atlas.en-us.252.0.api_meta.meta/api_meta/manifest_samples.htm

Note how you work with the standard Account object by specifying it as a member of a CustomObject type. However, you can’t use an asterisk wildcard to work with all standard objects; each standard object must be specified by name.

I thought that at one point, we had a warning explaining that if you needed sObjects, they had to be explicitly retrieved

using the sf project generate manifest --from-org command will generate a manifest with EVERY metadata type in your org, you can then remove what's not needed, but sObjects are listed under CustomObjects correctly

[codefriar]

@WillieRuemmele - Thanks for the quick reply.

I have ... any number of questions, but let me start of with this one. I know I'm a week late (to have talked to them at dreamforce) but ... who's the product owner for the metadata api? can you put us in touch? Seems like after ~60 versions of the metadata api, we can make this a thing, yes?

My proximate use case would result in multiple retrieve calls if i resort to using the package.xml. My org is too big to pull everything at once; hence the -m flags

[WillieRuemmele]

@codefriar - yes, the mdapi has it's known number of quirks, "features", and features 😉 - She's on twitter. Even with that said, the varied wildcard support of metadata is something we've had to work around while developing a lot of our libraries

[codefriar]

I reached out.

In the interim, I'm attempting to write a query that will identify customizations made to standard objects from the metadata catalog.