Code Inspector - polymorphic DuplicateRecordItem.Record relationship

[Eric Kintzer]

The following APEX generates a “Cannot resolve symbol Name". This is legit Apex as polymorphic relationships can be used to obtain the Name field.

‌

String recName = [SELECT Record.Name FROM DuplicateRecordItem][0].Record.Name;

‌

‌

[Scott Wells]

Hi, Eric. I'm not seeing that issue:

The polymorphic relationships are maintained in the OST under META-INF/PolymorphicRelationshipFields.json. What do you see for SCHEMA.DUPLICATERECORDITEM.RECORD? Here's what I have (and it will vary by the org, so yours won't likely be an exact match):

  "SCHEMA.DUPLICATERECORDITEM.RECORD": [
    "ACCOUNT",
    "AL__FOO__C",
    "CONTACT",
    "DLRS__DECLARATIVELOOKUPROLLUPSUMMARIES__C",
    "DLRS__LOOKUPCHILDAREALLYREALLYREALLYBIGBIGNAME__C",
    "DLRS__LOOKUPCHILD__C",
    "DLRS__LOOKUPPARENT__C",
    "DLRS__LOOKUPROLLUPCALCULATEJOB__C",
    "DLRS__LOOKUPROLLUPSUMMARYLOG__C",
    "DLRS__LOOKUPROLLUPSUMMARYSCHEDULEITEMS__C",
    "DLRS__LOOKUPROLLUPSUMMARY__C",
    "EXPENSE__C",
    "FILE__C",
    "FOO__C",
    "INDIVIDUAL",
    "LEAD",
    "NEBULA_TOOLS__ASYNC_TRIGGER_RUN__C",
    "NEBULA_TOOLS__MUTEX__C",
    "OBJECT_WITH_RECORD_TYPES__C",
    "ORDER__C",
    "OWNORGUNIT__C",
    "SHOPPINGLISTITEM__C",
    "SHOPPINGLIST__C",
    "TRANSACTION__C",
    "VALSKIP__C"
  ],

If that doesn't look correct to you, please regenerate your OST.

If that does look correct for you but still isn't working, please a) make sure you're on the latest builds of both the JetBrains IDE and IC2; b) rebuild your caches/indices.

[Eric Kintzer]

• I was on latest IDE and IC2;
• In META-INF I had no entry for SCHEMA.DUPLICATERECORDITEM.RECORD
• I refreshed caches and rebuilt OST ==> PROBLEM PERSISTS; still no entry for SCHEMA.DUPLICATERECORDITEM.RECORD
• DuplicateRecordItem is clearly known to IC2 as I can see its metadata in the objects folder

I’ve attached META-INF/PolymorphicRelationshipFields.json

I’m kind of surprised by all this as DuplicateRecordSet and DuplicateRecordItem should be in every org

[Eric Kintzer]

‌

‌

[Scott Wells]

Okay, I think I may know what's going on. Do you happen to have DuplicateRecordItem.object (metadata format) or DuplicateRecordItem/fields/RecordId.field-meta.xml (source format) as a local file in your project? If so, IC2 is using that to derive the relationship information, and when retrieved that field only includes:

<?xml version="1.0" encoding="UTF-8"?>
<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>RecordId</fullName>
    <type>Lookup</type>
</CustomField>

If you do have that locally, you can work around this by removing it. I'll need to think more about how I'd like to change this so that it uses information from both the local file (which when present is considered authoritative) and the API in these corner cases.

If you don't have that file locally, we'll need to get some trace-level logs from OST generation.

[Scott Wells]

Eric, let's see whether that works around the issue, but I've also implemented a change so that the polymorphic relationship information is recorded regardless of whether you have that field locally or not. That was just a bug and will be resolved in the next build (currently targeting Monday as it includes Summer '21 updates as well).

[Eric Kintzer]

I have /src/objects/DuplicateRecordItem.object (metadata format) in my project which includes only these fields as shown below

There’s clearly insufficient data solely from the .object file to know if the field is polymorphic; I would imagine you have to do a describe to discover that

‌

‌

    <fields>
        <fullName>DuplicateRecordSetId</fullName>
        <type>MasterDetail</type>
    </fields>
    <fields>
        <fullName>RecordId</fullName>
        <type>Lookup</type>
    </fields>

‌

[Scott Wells]

Yeah, that's the issue. And the changes I have locally for the next build fix that. I actually already have the describe information when this happens, but I wasn't using it in the logic branch where that object/field is available locally. That's the bug for which I have a fix. If you just move that out of the way for the OST generation, it should include the right polymorphic info. On Monday you won't need that workaround.

[Eric Kintzer]

Scott – I’ll wait until Monday as that is a better way for me to verify your fix (which is much appreciated btw). I’m sure it must be annoying to keep having me report these type issues but I love IC2 and when I see a symbol highlighted in red, I initially think it is some error I made in coding so the false positives throw me for a loop - especially since the code inspector is right 99.999% of the time. You and the IC community will get these edge cases stamped out.

Not surprisingly, I checked and String recName = [SELECT What.Name FROM Task][0].What.Name; also can’t evaluate as correct the trailing What.Name

[Scott Wells]

Regarding that other instance, yes, that's almost certainly the same thing. And totally fine waiting for the Monday build. I just regenerated and diffed all of my smoke test projects' OSTs with this change and it's holding up nicely. The only changes that I saw were exactly what I'd expect from this fix where previously missing entries are now properly present. I also created a new smoke test project where I generate the OST with no local object metadata and again with all object metadata retrieved, and I'm seeing some differences in the generated stub classes that need to be resolved, in particular with reciprocal relationship fields. I'm not going to try to rush that into Monday's build but will likely have a fix for that in the following build.

[Scott Wells]

Delivered in 2.1.8.1.

[Eric Kintzer]

it works! w/ latest version (summer 21 version)

[Scott Wells]

Glad to hear! Thanks for confirming the fix, Eric.