Last weekend, the sandbox for one of our active projects was updated to the Summer ‘13 Salesforce release. We discovered a nuanced issue related to the release that was affecting the Id.getSObjectType() method in Apex.
Update: It looks like other folks have identified this Summer ’13 glitch and are discussing some similar issues in this Force.com community thread.
There’s some moving parts here, so let’s set up a scenario. First, we have a Visualforce page which uses a standard controller (in this case, the Account object). This VF page references a Visualforce Component that exposes a “recordId” attribute. Basically, we’re passing the SFID of the record this VF page references down to the VF component:
The guts of the VF component looks like this:
The MyComponentController controller for the VF component looks like this:
Prior to Summer ‘13, this worked without any issues. However, after the release, we started getting low-level Salesforce “unexpected errors” when the recordId.getSObjectType() method was called.
It seems that, in Summer ‘13, Visualforce components are not correctly passing a Salesforce Id as a true Id data type. My best guess is it’s actually passing it as a String. Since getSObjectType() is not a method on the String data type, I think that’s where the unexpected Salesforce error kicks in.
To workaround this, we changed the recordId property in MyComponentController from an Id to a String data type. Next, we added a new property called recordSFID with a data type of Id, which we populate by casting recordId to an Id data type. Finally, we swapped our reference in the sot getting from recordId to recordSFID.
Final code is below:
Visualforce Page (no change here):
Visualforce Component (changes commented):
MyComponentController Apex Controller (changes commented):