sf project retrieve start -x "manifest/package.xml" fails with GACK error

[smo17]

Summary

Running command sf project retrieve start -x "manifest/package.xml" generates GACK. same issue when using IDE command SFDX: Retrieve source in manifest from org or running from sfdx-hardis plugin

 ────────────── Retrieving Metadata ──────────────

 Retrieving v62.0 metadata from username.com.org using the v63.0 SOAP API

 ✔ Preparing retrieve request 26ms
 ✔ Sending request to org 4.38s
 ✔ Waiting for the org to respond 14.11s
 ✔ Done 0ms

 Status: Failed
 Elapsed Time: 18.19s

Error (UNKNOWN_EXCEPTION): UNKNOWN_EXCEPTION: An unexpected error occurred. Please include this ErrorId if you contact support: 1287432555-62438 (-1073734177)

Steps To Reproduce

Package xml was already generated and available folder. Run command sf project retrieve start -x "manifest/package.xml" from bash terminal

Expected result

retrieved all metadata in package.xml from connected org

Actual result

Error (UNKNOWN_EXCEPTION): UNKNOWN_EXCEPTION: An unexpected error occurred. Please include this ErrorId if you contact support: 1287432555-62438 (-1073734177)

System Information

Running on bash

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.93.7",
  "nodeVersion": "node-v22.12.0",
  "osVersion": "Windows_NT 10.0.26100",
  "rootPath": "C:\\Users\\username\\AppData\\Roaming\\npm\\node_modules\\@salesforce\\cli",
  "shell": "C:\\Program Files\\Git\\usr\\bin\\bash.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.30 (core)",
    "@oclif/plugin-commands 4.1.26 (core)",
    "@oclif/plugin-help 6.2.28 (core)",
    "@oclif/plugin-not-found 3.2.56 (core)",
    "@oclif/plugin-plugins 5.4.40 (core)",
    "@oclif/plugin-search 1.2.24 (core)",
    "@oclif/plugin-update 4.6.43 (core)",
    "@oclif/plugin-version 2.2.29 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.41 (core)",
    "@oclif/plugin-which 3.2.35 (core)",
    "@salesforce/cli 2.93.7 (core)",
    "agent 1.23.0 (core)",
    "apex 3.6.19 (core)",
    "api 1.3.3 (core)",
    "auth 3.7.0 (core)",
    "code-analyzer 5.0.0 (user) published 55 days ago (Tue Apr 29 2025) (latest is 5.2.1)",
    "data 4.0.39 (core)",
    "deploy-retrieve 3.22.22 (core)",
    "info 3.4.66 (core)",
    "limits 3.3.56 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.8.0 (core)",
    "packaging 2.16.0 (user) published 10 days ago (Fri Jun 13 2025)",
    "schema 3.3.66 (core)",
    "settings 2.4.31 (core)",
    "sobject 1.4.60 (core)",
    "telemetry 3.6.44 (core)",
    "templates 56.3.50 (core)",
    "trust 3.7.98 (core)",
    "user 3.6.25 (core)",
    "sfdmu 4.38.0 (user) published 177 days ago (Sun Dec 29 2024)",
    "sfdx-git-delta 6.13.1 (user) published 17 days ago (Fri Jun 06 2025)",
    "sfdx-hardis 5.43.0 (user) published 2 days ago (Sun Jun 22 2025)",
    "texei-sfdx-plugin 2.8.3 (user) published 105 days ago (Mon Mar 10 2025)"
  ]
}

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

[smo17]

Looks like the issue is coming from the block WorkflowFlowAutomation present in package xml

        </types>
                <members>....</members>
		<name>WorkflowFlowAutomation</name>
	</types>

Removing the above block from package xml (API version 62 or 63) retrieves metadata successfully. I remember that error message was a bit more explicit a few months ago describing more clearly that WorkflowFlowAutomation is not supported or something. not sure why it is failing with error code now.

[wesnolte]

I'm having the same issue in several CI builds. The CI config hasn't changed; the jobs just started failing somewhere within the v64 rollout. Removing the WorkflowFlowAutomation section from the manifest lets me fetch the metadata, BUT I'm using a package.xml generated from that Org, so this isn't a solution for me. My workflow:

1. Clone the org's repo to the CI server
2. Generate a manifest for everything in a particular Org so that I know we're getting all metadata, i.e. sf project generate manifest
3. Pull all metadata using this manifest <- this step fails
4. Commit the changes to repo

We're an ISV with several Orgs on the way to the packaging org that we backup periodically in case of failure. I can't back these orgs up using CI at the moment because of the error.

[EstebanRomero84]

@smo17 That error message indicates that the error comes from the server, not from the cli. The change in the message that you mentioned is because we added support for WorkflowFlowAutomation in version 2.88.6. Before that version, the cli didn't support that metadata type so it couldn't send the request to the server. Now the cli sends the request and the response is an error.

I'm investigating the GACK, I'l post here if I find something.

[EstebanRomero84]

Update: it is a bug in the Metadata Framework (W-18887504). The owning team is working on a fix.

[wesnolte]

@EstebanRomero84 thanks, and yes it seemed to be a metadata issue but I wasn't clear how I could submit a bug to that team. Could you let me know so I can do so in future?

[nvuillam]

Do we have an estimated ETA for the fix ? And will it be delivered as a SF Cli version or pushed on SF Platform ?

This bug totally breaks sfdx-hardis monitoring (so no more daily backups of orgs) 😢

[cristiand391]

closing this, the WI mentions the bug was fixed in a 256 patch, the fix should make the API handle errors gracefully instead of throwing a gack.