sf project retrieve start --package-name is fetching Managed Packages without namespace

[Amit-Tripathi]

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

Retrieving Managed Package from the org brings metadata without Namespaces

Steps To Reproduce

1. Spin a Project and create a scratch org
2. Create a managed package in a dev org with a custom object, fields & layout, or use the one i mentioned below
3. Install a Managed package in Scratch Org. I used Managed Beta, feel free to install this package for repro [https://login.salesforce.com/packaging/installPackage.apexp?p0=04tak00000023WT]
4. Run sf project retrieve start --package-name OrgBrowser command if you installed the package I mentioned. Or use the name of the package you created
5. Metadata will be retrieved in a separate directory, open Objects directory. Object metaxml file doesn't have the namespace.

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.

Expected result

The managed Package metadata should have been retrieved with the namespace.

Actual result

The managed Package metadata doesn't have the namespace. So if I make any changes like adding a field to the managed custom object in the project and deploying it will not update that object but rather creates a new object or update some existing object.
Refer to the screenshot below, same object when retrieved via manifest has namespace orgbrowser__hello but when retrieved via command sf project retrieve start --package-name it creates a OrgBrowser folder and has the object listed as just hello without namespace.

System Information

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.45.6",
  "nodeVersion": "node-v20.13.1",
  "osVersion": "Windows_NT 10.0.22631",
  "rootPath": "C:\\Users\\amit.tripathi\\AppData\\Local\\sf\\client\\2.45.6-3aaf41e",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.1.2 (core)",
    "@oclif/plugin-commands 4.0.2 (core)",
    "@oclif/plugin-help 6.1.0 (core)",
    "@oclif/plugin-not-found 3.2.2 (core)",
    "@oclif/plugin-plugins 5.2.2 (core)",
    "@oclif/plugin-search 1.1.1 (core)",
    "@oclif/plugin-update 4.3.3 (core)",
    "@oclif/plugin-version 2.2.2 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.4 (core)",
    "@oclif/plugin-which 3.2.1 (core)",
    "@salesforce/cli 2.45.6 (core)",
    "apex 3.1.14 (core)",
    "auth 3.6.17 (core)",
    "data 3.4.3 (core)",
    "deploy-retrieve 3.8.4 (core)",
    "info 3.3.4 (core)",
    "limits 3.3.10 (core)",
    "marketplace 1.2.10 (core)",
    "org 4.1.19 (core)",
    "packaging 2.4.5 (core)",
    "schema 3.3.10 (core)",
    "settings 2.3.0 (core)",
    "sobject 1.4.8 (core)",
    "source 3.3.21 (core)",
    "telemetry 3.3.12 (core)",
    "templates 56.2.9 (core)",
    "trust 3.7.4 (core)",
    "user 3.5.11 (core)"
  ]
}

Additional information

[github-actions]

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]

The CLI writes the file paths from the Metadata API response and that's how they are sent when the --package-name flag is set. That affects the RetrieveRequest made to the metadata API and it's not clear from the docs (here) what the expected behavior is. I'll ask that team if this is a bug or working as designed.

[github-actions]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[shetzel]

After some investigation, the retrieve command behavior with the --package-name flag is working as designed. However, as a result of this issue and the support case there will be multiple doc updates to clarify expectations. Thank you for bringing this to our attention.

History: the packageNames attribute on the RetrieveRequest was originally added to support the now deprecated Eclipse IDE and was meant more as a reference than metadata to be source controlled for deploys and retrieves.

The directory contains a lot of Metadata that will not redeploy to the org, for instance the Apex classes are just stubs and the user has no permission to modify the Apex classes in a Managed Package.

Metadata is represented differently based on its container. In this context it is assumed that it exists in the Package container, the Metadata is not fully qualified with the Package's Namespace. This is similar to how an Apex class in Namespace Foo can access other classes in the same Namespace without full qualification.