Too much Custom Metadata can be bad for you :)

Last week we saw an interesting issue where a customer had trouble deploying Custom Metadata using Gearset. Gearset stopped comparing the customer’s orgs when we encountered a duplicate CustomMetadata component. How on earth did we get two CustomMetadata records with the same name?

Gearset is designed to stop when it finds something that it doesn’t understand about an organization: this ensures that we don’t try to deploy inconsistent metadata, potentially causing problems with the target organization. On the occasions this has happened before, it has turned out to be a problem with the way that Gearset interprets the metadata from Salesforce.

This case turned out a little differently, however. As part of the comparison we inspect the organizations using the Metadata API and make a retrieve() call to request metadata using a custom package.xml for all of the metadata we’re interested in. What was happening was that the organization was reporting that it had two CustomMetadata components with the same name, differing only in case (ie, one called ‘Foo’ and one called ‘foo’). Salesforce is normally case-insensitive and so when we asked for both by name it was becoming confused - not only did it seem that we were asking for the same thing twice, it was finding two distinct components for each of the two requests. This manifested itself in Salesforce failing to complete the retrieve() request with the following error message:

UNKNOWN_EXCEPTION: An unexpected error occurred. Please include this
ErrorId if you contact support: 523720514-14309 (-1752120718)

Very useful Salesforce! Sometimes I wish they would give us just a little more info behind the GACK error!

Gearset then automatically tried a different approach to the retrieve and instead used apackage.xml with a wildcard for the CustomMetadata type. Weirdly, this retrieve() worked and Salesforce returned both records to us but now the comparison engine that powers Gearset got confused as it was seeing two objects that apparently had the same name which should never be possible in Salesforce metadata!

This, it turns out, is something that’s possible to do due to a bug in the Salesforce UI. Under a particular custom metadata type, it’s possible to create two labels that have the same name but differ only in case, which seems to work fine until it encounters a part of Salesforce that works case-insensitively, like the metadata API.

The only real fix for this issue is to edit the organization so that the duplicate name is changed to something unique. It’s not possible to deploy this setup via the Metadata API, which is probably a good thing as this situation means that the metadata in the organization is inconsistent. We’ve let Salesforce know about the issue, and it’s no longer possible to create custom metadata with duplicate names in this way.

For Gearset, we decided we wanted to keep it working for the rest of the organization even when this problem existed. It’s not possible to download this metadata successfully, so our workaround is to remove these duplicates from the comparison: this makes it possible to work with these organizations until the underlying problem is fixed.

This was a very weird case and shows that even in software as reliable and well-tested as Salesforce you can find the occasional oddity! I will finish this tale by thanking our awesome user Wes that worked with us in diagnosing just what part of his org made Gearset particularly grumpy.

This is just one example of the hundreds of things Gearset is doing to ensure that your deployments work reliably and simply. Take our 30-day free trial for a spin.