Cannot locate Apex Type for ID CaseComment

[aheber]

I get this error when trying to rollup from CaseComment

Error: Invalid Data.
Review all error messages below to correct your data.
Apex trigger dlrs_CaseCommentTrigger caused an unexpected exception, contact your administrator: dlrs_CaseCommentTrigger: execution of AfterInsert caused by: System.SObjectException: Cannot locate Apex Type for ID: 00aS00000027nijIAA: (dlrs)

You can reproduce this error in Anonymous Apex:

Id myId = '00aS00000027nijIAA';

SObjectType childObjectType = myId.getSObjectType();
System.debug(childObjectType);

I'm not sure what the solution is as this seems to be a Salesforce bug. I couldn't find this reported in any known issues, but I'm generally new to Salesforce and could just not know where to look.

I'm going to pursue this through other channels, and will update this issue as I gather information.

Any short-term solutions short of very specific workarounds would be appreciated. Worst case I might write a small patch to my version just to meet my business objectives until something else presents itself.

[afawcett]

Yes that is most odd and i agree on the face of it something that feels like a platform issue. Appreciate your investigation into this, please let me know either way. If the tool needs to workaround this limitation with the CaseComment object I've got some thoughts on that. Let me know anyway, and we will for sure sort this out one way or another! 👍

[afawcett]

Any news from Salesforce on this? (btw noticed your post on StackExchange also.. ;-) )

[aheber]

I have an open case but no news as of yet. I imagine we'll need a workaround to get this project to handle the CaseComment object for a while, even if it is a failing in the platform I doubt it will be fixed overnight.

[afawcett]

Ok let me figure out how to fix this, might take me a couple of weekends though....

[aheber]

I have interim update from Salesforce that the problem has made it all the way to R&D. I'm still waiting for any official declaration of bug or unsupported.

I'll update again when I get more info.

[aheber]

I received this from Salesforce.com support today, looks like we're on our own:

"When you call the getSObjectType() Apex method to an Id object to get an sObjectType from the Id, we internally call the method and try to get a Type from an entity info returned from it. And in this method call, an entity info is retrieved from a key prefix of the specified Id. However, if the key prefix points to a template entity, the method call returns null since template entities cannot reveal their entity infos. In case of CaseComment, it shares its key prefix with CaseObjectComment. So, when we try to obtain the entity info using an Id of a CaseComment, we do that through CaseObjectComment. But, since CaseObjectComment is a template entity, we cannot get its entity info. It causes the issue.

IdeaComment shares its key prefix with CaseObjectComment, too. So the same issue occurs when calling getSobjectType() Apex method to an Id of an IdeaComment."

[afawcett]

Ok, lets press on with a fix, want to help?

[aheber]

Absolutely. I should warn you I'm rather new at this and haven't reviewed your framework yet. I don't how much help I would be.

My initial thoughts are that we need to build a wrapper class on getSObjectType to extend it that we call to get the object type. Given the duplication of the object prefix we likely need to look at the objectid of the parent to help determine the object type. I can't think of a way to do this without some hardcoded comparisons. Mostly because I don't know a lot of tricks :)

If I'm way off let me know, my feelings won't be hurt. I would appreciate the opportunity to learn.

[afawcett]

So sorry for not getting back to you on this, the truth is i've been revisting it a few times and pondering it briefly then getting distracted and having to come back to it. I've finally been able to give it some clear thinking time.

What we can do is enhance the generated trigger to pass into the triggerHandler method the SObjectType of the Child object, we can make this an overloaded method so existing triggers that don't pass it still work and obtain it via the Id, but for new triggers they get it passed in, e.g.

trigger dlrs_CaseCommentTrigger on CaseComment
    (before delete, before insert, before update, after delete, after insert, after undelete, after update)
{
    dlrs.RollupService.triggerHandler(CaseComment.SObjectType);
}

This would be an change to the triggerHandler method and the RollupController.cls. What do you think?

BTW, how did you manage to create such a rollup on CaseComment, i don't see any candidate fields on this object and you cannot add custom fields? Can you show a screenshot of your rollup definition please.

[bradcis]

hey @afawcett, is there any movement on this one?

[afawcett]

I'll take a look at this next time i get a burst of dev time on the tool.

[skamensky]

Thanks for looking into this guys. I'm dealing with an issue unrelated to DLRS and this helped me out. Just in case anyone else sees this I ran into this issue with the a CustomShare object, which shares its id prefix with any other CustomShare object. SALESFORCE OYYY.

[afawcett]

Thanks for sharing @skamensky 👍

[afawcett]

v2.9

[KevinBR72]

After some digging, and experimenting, this appeared to work for me:
(called from after insert, after update, and after delete sections in trigger class)

private void declarativeRollupSummary (map<Id,CaseComment> mapOldRecs,map<Id,CaseComment> mapNewRecs) { dlrs.RollupService.rollup(mapOldRecs,mapNewRecs,CaseComment.SObjectType); }