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

[iowillhoit]

Hey @dschibster, thank you so much for the repro! I was able to see those same results. However after I got that error I looked at the repo and noticed that you are using decomposePermissionSetBeta instead of decomposePermissionSetBeta2. Are you able to see the same error with decomposePermissionSetBeta2?

[dschibster]

Hi @iowillhoit, you are right, that issue was on me for not using the right decomposePermissionSetBeta setting. Is the first one even going to be worked on anymore?

To answer your question, the error does not persist in beta2, now my object settings contain the field Permissions, the field permissions are not retrieved as separatefiles. If it stays like this I'd be less inclined to even use the decomposition.

What I did:

• Delete the permset from the repo
• reset my tracking
• update my sfdx-project.json
• edit my permission set on my scratch org again
• retrieve it with sf project retrieve start -m PermissionSet:Account_Permissions

DId I do something wrong, are the two betas looking completely different in terms of decomposition method?

[iowillhoit]

We are not planning on continuing development on the decomposePermissionSetBeta preset.

The decomposePermissionSetBeta2 is the result of community feedback here: #2993

The vote (and following conversations) decided that "focused decomposition" was the best route. Part of this focused decomp was that Object settings are stored in single files.

[dschibster]

Absolutely fair, and my bad for not noticing this earlier. Then I will say that this issue here is closed as I have been doing it wrong all along!