decomposePermissionSetsBeta2 retrieves the right files but complains about metadata type inference

[dschibster]

Summary

When using decomposePermissionSetsBeta2 and retrieving a Permission Set into a temp folder which already has existing permission Files in another project folder, the files get retrieved into the temp folder and CLI will throw an error about inability to infer a metadata type.

Steps To Reproduce

• Create a project with two project folders, of which one is the default folder
• Create a Permission set in the non-default folder and fill it with the necessary definition meta files
• Edit permissions in the UI
• Retrieve
• The changed files will be retrieved, but the error will still occur.

Expected result

One of two options should occur:

• Either the files should already be migrated into the correct permission set folder
• Or the files should simply be retrieved without any error output

Actual result

This is done via the VS Code Extension, but it also comes up when using sf project retrieve

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.71.6",
  "nodeVersion": "node-v22.9.0",
  "osVersion": "Darwin 24.1.0",
  "rootPath": "/opt/homebrew/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.14 (core)",
    "@oclif/plugin-commands 4.1.14 (core)",
    "@oclif/plugin-help 6.2.19 (core)",
    "@oclif/plugin-not-found 3.2.31 (core)",
    "@oclif/plugin-plugins 5.4.22 (core)",
    "@oclif/plugin-search 1.2.17 (core)",
    "@oclif/plugin-update 4.6.18 (core)",
    "@oclif/plugin-version 2.2.18 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.28 (core)",
    "@oclif/plugin-which 3.2.21 (core)",
    "@salesforce/cli 2.71.6 (core)",
    "apex 3.6.8 (core)",
    "api 1.3.2 (core)",
    "auth 3.6.82 (core)",
    "data 3.13.5 (core)",
    "deploy-retrieve 3.16.0 (core)",
    "info 3.4.29 (core)",
    "limits 3.3.43 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.11 (core)",
    "packaging 2.4.5 (user)",
    "schema 3.3.45 (core)",
    "settings 2.4.9 (core)",
    "signups 2.0.13 (link) /opt/homebrew/lib/node_modules/@salesforce/plugin-signups",
    "sobject 1.4.46 (core)",
    "telemetry 3.6.27 (core)",
    "templates 56.3.34 (core)",
    "trust 3.7.51 (core)",
    "user 3.6.5 (core)",
    "sfdmu 4.33.17 (user)",
    "sfdx-git-delta 5.40.0 (user)",
    "sfdx-hardis 4.52.0 (user)"
  ]
}

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

[iowillhoit]

Hey @dschibster, I messed with for a while today and I am unable to get that same error.

Could you please put together a simple Github repo with step-by-step commands to reproduce this issue? You could either start with Dreamhouse or with sf project generate

Thank you!

[dschibster]

@iowillhoit https://github.com/dschibster/permission-set-decomposition

Here's a repo where I was able to reproduce the issue.
To reproduce this, simply create a new scratch org and deploy the permission set there. Then add a new field permission to the Account_Permissions permission set and run sf project retrieve start. The metadata files should be retrieved into the force-temp folder, but the CLI will still throw an error.

This is what the Error looks like when directly executing the sf command