Subscription editor is saying org contents have changed when they haven't

[Scott Wells]

I had a user report that when using the refresh button/link to update IC2 with the latest list of org metadata, it's saying that pretty much everything has changed and expanding all metadata type branch nodes in the subscription selection tree. I'm using this issue to track that problem and to gather diagnostic info to help debug it.

[Scott Wells]

Install this build and add the following to Help>Diagnostic Tools>Debug Log Settings:

#com.illuminatedcloud.intellij.settings.module.ModuleSubscriptionEditor

then open the subscription editor click the refresh toolbar button or link. Assuming that reproduces the behavior, shoot over the log to me via email. Redact anything you'd like, but I really need to see the exact information in the entries that look like:

The contents for metadata type <type> have changed:
  Before: { ... }
  After:  { ... }

[Scott Wells]

You know what...hold off. I think I've figured this out. If so, I'll post a new build shortly with the prospective fix so that you can verify it.

[Scott Wells]

Okay, so the issue is that anything that's subscribed via wildcard ends up with the empty set getting compared to the latest set of metadata names for that type. I can go two ways on the fix:

1. When a type is wildcarded, I can just never mark it as changed even if what * meant before the refresh is different from what it means after.
2. If the locally-cached list of metadata for that type is different before vs. after AND the type is wildcarded, I can decide that the user might want to see that the meaning of * has changed and notify them of the change.

The latter can end up being noisy when multiple types are wildcarded, but it's explicit. However, given that IC2 doesn't actually show you what's been added/removed, and that wildcards are generally most useful when you have a larger numbers of entries for a given type, it may just end up being that...noise. As a result I'm leaning toward the first option where a change to the entries for a wildcarded type doesn't result in notification. As a user, do you have a strong feeling on this?

[Tony White]

We generally use the ‘Selected’ metadata option, and tick the different types we need. Looking at the package.xml it generates there are no wildcards used.

All of the before’s are empty eg

2021-05-18 06:57:12,691 [ 286823] DEBUG - odule.ModuleSubscriptionEditor - The contents for metadata type AssignmentRule have changed:
Before: { }
After: { CASE.DEFAULT CASE OWNER, LEAD.STANDARD }

But I am thinking that it might be easier to do option 1, then rely on the Retrieval screen option of Server only to show what is missing locally, if you are wanting to check what is updated. Though as mentioned that is a problem currently for us with our Case object showing it is not locally available even though it is…

‌

[Scott Wells]

Even in a Selected metadata subscription, when you click on the metadata type branch node, you'll notice that it shows a little [*] beside the type name. That means that it's going to try to maintain that type as a wildcard as you update/refresh the list of server metadata objects. If you look in the .iml file where it maintains the checked entries for a `Selected metadata subscription, you'll see something like:

<MetadataType>
  <option name="name" value="ApexClass" />
 </MetadataType>

which, by omission of <option name="wildcard" value="false" />, indicates that type is wildcarded.

So the same issue exists for both Package.xml and Selected metadata subscriptions that I described previously.

I've been working on this a bit today and should finish the fix tomorrow. At present I'm tracking toward the second option because it's more consistent with the current implementation (in fact, that's what it was already trying to do). Once I have it worked out I can post a new build here for you to try.

[Scott Wells]

Delivered with 2.1.7.8.