sf project retrieve start --target-metadata-dir flag causing error

[jxbambrick]

Summary

The command "sf project retrieve start --target-metadata-dir output --package-name placeholder" is causing an error when using the --target-metadata-dir flag.

Steps To Reproduce

1. sf project generate --name test-delete
2. set default-org
3. create a change set in the selected default-org
4. sf project retrieve start --target-metadata-dir placeholder1 --package-name placeholder2
5. see terminal for error message: Error(1): unknown

Expected result

1. A new local salesforce project should be created called test-delete
2. The default org should be selected
3. A change set should exist in the outbound change set folder
4. SF project retrieve start --target-metadata-dir placeholder1 --package-name placeholder2 should download the package placeholder2 into the folder placeholder1

Actual result

1. Terminal displays an error: Error(1)

System Information

1. Using Windows 10 Enterprise: Visual Studio Code: Terminal is PowerShell and cmd
2. @salesforce/cli/1.83.0 win32-x64 node-v18.15.0
3. sfdx-cli/7.205.6 win32-x64 node-v18.15.0

{
"cliVersion": "@salesforce/cli/1.83.0",
"architecture": "win32-x64",
"nodeVersion": "node-v18.15.0",
"osVersion": "Windows_NT 10.0.19044",
"shell": "cmd.exe",
"rootPath": "C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf",
"pluginVersions": [
"@oclif/plugin-autocomplete 2.3.0 (core)",
"@oclif/plugin-commands 2.2.15 (core)",
"@oclif/plugin-help 5.2.9 (core)",
"@oclif/plugin-not-found 2.3.24 (core)",
"@oclif/plugin-plugins 3.1.2 (core)",
"@oclif/plugin-search 0.0.17 (core)",
"@oclif/plugin-update 3.1.17 (core)",
"@oclif/plugin-version 1.3.4 (core)",
"@oclif/plugin-warn-if-update-available 2.0.37 (core)",
"@oclif/plugin-which 2.2.22 (core)",
"@salesforce/cli 1.83.0 (core)",
"apex 2.3.3 (core)",
"auth 2.8.1 (core)",
"data 2.3.22 (core)",
"deploy-retrieve 1.11.7 (core)",
"info 2.6.19 (core)",
"limits 2.3.18 (core)",
"login 1.2.11 (core)",
"org 2.9.8 (core)",
"schema 2.3.12 (core)",
"settings 1.4.11 (core)",
"sobject 0.1.24 (core)",
"source 2.10.14 (core)",
"telemetry 2.2.0 (core)",
"templates 55.4.20 (core)",
"trust 2.4.20 (core)",
"user 2.3.17 (core)"
]
}

Additional information

Running the following command works as expected: sf project retrieve start --package-name placeholder2
Other iterations of the sf project retrieve start work as expected except when including --target-metadata-dir
Issue experienced in previous version of sfdx and sf.
This issue started: 6/15/2023

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

[WillieRuemmele]

Hey @jxbambrick - from the --helpoutput, the --target-metadata-dir is Directory that will contain the retrieved metadata format files or ZIP.

maybe try using the

-r, --output-dir=<value>       Directory root for the retrieved source files.

[jxbambrick]

This isn't supported. I tried this as a workaround but also got an error:

PS C:\Users\josh.bambrick\Documents\Github\test-delete\test-delete> sf project retrieve start --package-name placeholder --output-dir md --json
{
"code": 1,
"context": "RetrieveMetadata",
"commandName": "RetrieveMetadata",
"message": "The following error occurred:\n \u001b[2m--package-name=placeholder cannot also be provided when using --output-dir\u001b[22m\nSee more help with --help",
"name": "Error",
"status": 1,
"stack": "Error: The following error occurred:\n \u001b[2m--package-name=placeholder cannot also be provided when using --output-dir\u001b[22m\nSee more help with --help\n at validateFlags (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\parser\validate.js:52:19)\n at async validate (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\parser\validate.js:158:5)\n at async Object.parse (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\parser\index.js:19:5)\n at
async RetrieveMetadata.parse (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\command.js:221:25)\n at async RetrieveMetadata.run (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@salesforce\plugin-deploy-retrieve\lib\commands\project\retrieve\start.js:30:27)\n at async RetrieveMetadata._run (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\command.js:117:22)\n at async Config.runCommand (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\config\config.js:329:25)\n at async run (C:\Users\josh.bambrick\AppData\Local\sfdx\client\7.205.6-dfc6717\sf\node_modules\@oclif\core\lib\main.js:89:16)",
"exitCode": 1,
"warnings": []
}

[jxbambrick]

This error is experienced in a Python deployment pipeline but was manually confirmed with the above steps in multiple projects. The code explicitly downloads the change set in metadata format and then, in a later step converts it into source format. The code hasn't changed but it looked like there was an update released yesterday which aligns with when the issues started. To simplify the error and limit troubleshooting I removed the extra flags such as --json --api-version, and --unzip.

[jxbambrick]

Removing --target-metadata-dir md results in the change set downloading but in the project source directory. Here is a screenshot:

[mshanemc]

what happens with --target-metadata-dir and --json ? do you get a better error message?

You can also try force:mdapi:retrieve -w 1000 with that same package and see if that produces a more useful error.

We're going to fix this so it provides better error output.

[git2gus]

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

[jxbambrick]

The JSON error message does not provide any more information.

[jxbambrick]

Not sure if I ran the command correctly: sf force:mdapi:retrieve -w 1000 --target-metadata-dir md --package-name test-changeset --json

Here is the screenshot:

[sanyaburba]

Hello everybody, have a same issue. Did someone find the solution?

[jxbambrick]

It should be resolved in the next couple of weeks since it was assigned to a work item. There are weekly releases every Wednesday. If you are able, try upgrading to the latest version. I uninstalled sfdx/sf and reinstalled using npm. This has enabled me to cherry-pick specific versions and experiment with which version will work for my project needs.

[mshanemc]

I followed these steps on the current CLI and it retrieved a change set.