Profile reconciliation is removing components from the profile that are in the org

[jhawk-4]

Describe the bug
As of Fri, 28 Feb 2025 17:13:44 GMT, our profile reconciliation process has started to fail. Our profiles that have custom applications set as the App default are having the applicationVisibilities removed for the custom apps despite the applications being deployed to the org. This is resulting in the error message You can't remove the only default app from the profile.

NOTE: This only happens if the sfpowerkit-cache.db exists prior to the custom application being deployed. If the cache is reset and then the process is repeated the applicationVisibilities tag is not removed. It also appears to be related to applicationVisibilities, because I tried the same process with <fieldPermissions> and those did not get removed.

UPDATE: It is not isolated to just one metadata type. I was able to reproduce the issue with other metadata types. More details in comment below.

To Reproduce

• Create a scratch org
• Initialize the sfpowerkit-cache.db by running a reconciliation before the application is deployed
• Deploy a custom application to the org
• Verify that application exists in the org by running sf org list metadata --metdata-type CustomApplication
• Create a local profile and set the <applicationVisibilities> for the custom application to have <default>true</default> and <visible>true</visible>
• For all other standard applications set the default and visible tags to false
• Run sfp profile reconcile -n "NameOfProfile" -o {orgalias}

Expected behavior
applicationVisibilities section for the Custom Application that exists in the org should remain in the profile

Actual behavior
applicationVisibilities section for the Custom Application that exists in the org is removed from the profile.

Screenshots
If applicable, add screenshots to help explain your problem.

Platform Details (please complete the following information):

• OS: macOS Sequoia 15.3.1
• Version 39.4.1 and 39.5.1
• Salesforce CLI(sfdx cli) Version: 2.78.3
• CI Platform: github actions

Additional context
There is a deprecation warning in the terminal window that seems to have started around the same time that this stopped working. I'm including that here

(node:20332) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
    at node:punycode:3:9
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:399:7)
    at BuiltinModule.compileForPublicLoader (node:internal/bootstrap/realm:338:10)
    at loadBuiltinModule (node:internal/modules/helpers:108:7)
    at Function._load (node:internal/modules/cjs/loader:1099:17)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
    at Module.require (node:internal/modules/cjs/loader:1339:12)
    at require (node:internal/modules/helpers:135:16)
    at Object.<anonymous> (/usr/local/lib/node_modules/@flxbl-io/sfp/node_modules/whatwg-url/lib/url-state-machine.js:2:18)

[mikewilson4]

I believe I am also experiencing this issue. For me it was a tab visibility setting for reports and dashboards. Set in file, but not reflecting in the org. This is on sfp-rc:39.5.1-13409618031 too.

[jhawk-4]

We also had a discussion about this in slack, but I'll share some detail here for others. In our instance, the reason is related to how the cache is being built and accessed. I'm honestly trying to figure out how this worked from the beginning for us, but haven't tracked that down just yet. Here is the context for our situation. The cache used in .sfdx/sfpowerkit/sfpowerkit-cache.db is initialized when the reconciliation command is first run. The keys for the cache are being set as the metadata types related to the profile permissions

applicationVisibilities => CustomApplication, classAccesses => ApexClass, fieldPermissions => CustomField, etc

We have a profile in package1 that has a reference to CustomApplication, we'll call it App1. When package1 is installed and profile reconciliation runs against the destination org, the cache for CustomApplication is populated with all of the references from the profile that are in the destination org. Because none of the CustomApplications are deployed yet the cache is built from all of the Standard Applications that are referenced in the profile and all the custom application references are removed. After, the first deployment, the profiles are restored to their previous state and reconciled again. However, since the cache key has already been established, the org is not checked for the new components, and so they are removed again and no permissions updates are applied to that CustomApplication. Where this can cause deployment failures is if you are attempting to set your default application as one of these custom applications and you are explicitly setting your standard applications as not visible. Salesforce will throw a deployment error at that point, which is what happened in our case.

Where will this cause problems?

• You are putting profiles and their referenced metadata in the same package and the referenced metadata does not exist in the destination org yet. (eg Scratch org prepare or net new metadata)
• You have a package with a profile that is reconciled and then have subsequent deployments with metadata types that are referenced in the previously reconciled profile and then you reference the subsequently deployed metadata in later packages with profiles. (this was our very complex scenario)

How can you avoid the problem until a fix is released?

• Combine your profiles into a single package and ensure that the metadata they reference has been deployed by previous packages
• If you do separate profiles, avoid running reconciliation within multiple different packages. Isolate your profiles that need to be reconciled and combine them together so that reconciliation only runs once for all of those profiles.