Metadata (SharingRule) missing in retrieve/refresh when Module Subscription is "All"

[Piotr Kożuchowski]

I’m totally puzzled by this one. When I retrieve/refresh sharing rules in IC2, one of the rules is missing. It’s visible in the sandbox though.

I’ve tried to retrieve the file in workbench and through sfdx and it’s there, so somehow IC2 is not retrieving it. My module is set to subscribe to All/Pacakge.

As I’m writing this, I’ve tried to go to Configure Module and click “Update Now” and it helped, so it seems there’s some caching involved.

This is course of action as it happened and probably reproduction step:

1. Sharing rule was manually added on sandbox
2. I’ve tried to refresh it in IC2
3. IC2 did not retrieve new sharing rule
4. Clicked on Configure Module → Refresh Subscription
5. Refresh brought up new rule.

‌

Kind Regards

[Piotr Kożuchowski]

PS. I’ve retrieved from different connection and sharing rules are missing again! They are definitely on the sandbox

[Piotr Kożuchowski]

Another reproduction steps:
1. Rename existing sharing rule
2. Refresh sharing rules in IC2
3. Observe renamed sharing rule disappear
4. Refresh subscription in Configure Module (Subscription All/Package)
5. Refresh file and sharing rule is there.

[Scott Wells]

Do I understand that Update Now helps consistently? Yes, IC2 caches the server metadata list aggressively. On densely-populated orgs, querying that list--even using multiple concurrent threads--can be an expensive operation. As a result IC2 caches the list and displays the time stamp of that cache with a convenient way to refresh it. If metadata has been changed in the org since that cache was populated--and that's metadata you care about--you'll need to refresh the cache after which is should be consistent. If that's not the case, we'll need to get debug logs so I can see what's going on.

[Piotr Kożuchowski]

I mean it kind of does, but it’s very counter intuitive and it’s not behavior that I’d ever expected. It may have had sense if entire Account.sharingRules was missing and I’ve tried to retrieve it, but that’s not it.
Sharing Rules exist in branch, rules exist in org, rules exist in my local file, BUT refresh/retrieve remove those rules from my local file because they are not in IC2 cache.

See, if I retrieve package.xml bellow using either workbench or sfdx force:mdapi:retrieve, I will retrieve ALL sharing rules and that’s expected behaviour.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account</members>
        <name>SharingRules</name>
    </types>
    <version>52.0</version>
</Package>

Meanwhile in IC2 refreshing Account.sharingRules file will retrieve only rules which it had cached during the last time I’ve clicked Update Now in module config and until now, I’ve never thought I had to do that while using “All” subscription.
In other words, when I’m refreshing/retrieving entire Account.sharingRules file with IC2, the package.xml that it’s built by IDE contains particular rules instead of entire file and that behavior is very misleading:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.Region_International_Account_Access</members>
        <name>SharingCriteriaRule</name>
    </types>
    <version>52.0</version>
</Package>

Moreover, I’ve noticed this behavior reappear after retrieve from another connection and while changing module connection.

‌

[Scott Wells]

Even an All/Package subscription is going to build out its manifest based on the server metadata that it know about. For metadata types that support wildcarding, that works fine, but for those that don't, you must refresh the list of metadata when you know that it's changed on the server so that such a subscription picks it up.

Note that for the most part I also discourage the use of All/Package subscriptions unless they're being used for managed package development where a development package is selected as a metadata filter. Some metadata that's included in the server's list cannot be retrieved, and some metadata that can be retrieved cannot be deployment...sometimes even back to the exact same org. Honestly I'm probably going to remove that option and automatically migrate those subscriptions to either Package.xml or Selected with all known metadata pre-selected. It accomplishes the same goal, but it forces some diligence around what gets included in the metadata subscription. Using your specific example, you would explicitly subscribe to SharingRules > Account vs. IC2 blowing that out to the distinct child metadata members.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.