Many system types in the OST lack proper field type information

Issue #821 resolved
Doug Ayers created an issue

Trying to reference nested fields on DuplicateRuleHeader of DMLOptions object is flagged as unresolvable entity even though it's valid.

I think this stems from the auto-generated DMLOptions class' properties are type Object instead the specific types like AssignmentRuleHeader, DuplicateRuleHeader, etc.

I manually modified the OST such that the on the DMLOptions class:

global Object DuplicateRuleHeader;


global DuplicateRuleHeader DuplicateRuleHeader;

and that made the field resolvable again.

Any chance when the DMLOptions class is generated it can have its properties typed rather than just Object?



Comments (25)

  1. Scott Wells repo owner

    Yep, I ran into a few of these over the weekend as well, in my case in Messaging.InboundEmail. The fields/properties of these system types are reported as completely untyped by the Salesforce APIs. In cases where there are strongly-typed accessor methods in the same type, I adjust at OST generation time to render a more strongly-typed OST overall, but in cases like this I just don't have anything to use for better type information.

    I've reported this to Salesforce and they know about the general class of issue, but I have no idea if/when it will be addressed. I actually do have a mechanism to fix these types of things in a hard-coded form during OST generation and do so for a small subset of commonly-accessed system types, but when I looked into doing the same thing for this pervasive issue...honestly, I found myself a bit overwhelmed and decided to wait for someone to report them here.

    Let me follow up again with Salesforce. It's possible with the new Apex Language Server they do have a better solution for this now. Cross your fingers!

  2. Scott Wells repo owner

    Okay, I pinged them. We'll see what they say. In the interim, it seems like DMLOptions is important enough to warrant hard-coded corrections during OST gen. I'll work that one into an upcoming build.

  3. Scott Wells repo owner

    Yep. Ignoring the ConnectApi namespace which is FULL of these things (and frankly just doesn't seem entirely baked in terms of online documentation, etc.), here are the classes which seem to have this issue in some form (ordered by number of fields of type Object descending):

    Messaging.InboundEmail - 28
    Metadata.Layout - 23
    Metadata.DeployResult - 23
    Metadata.PlatformActionListContextEnum - 19
    Metadata.LayoutItem - 14
    Database.DMLOptions - 14
    Metadata.DeployMessage - 13
    WaveTemplate.VariableTypeEnum - 12
    Process.PluginDescribeResult - 12
    Metadata.FeedLayoutComponentType - 11
    Metadata.FeedLayout - 10
    Metadata.AnalyticsCloudComponentLayoutItem - 10
    Metadata.SidebarComponent - 9
    TxnSecurity.Event - 8
    Metadata.ReportChartComponentLayoutItem - 8
    Canvas.Test - 8
    Metadata.Container - 7
    ApexPages.Component - 7
    Metadata.SummaryLayout - 6
    Metadata.RelatedListItem - 6
    Metadata.LayoutSection - 6
    Metadata.SummaryLayoutItem - 5
    Metadata.PlatformActionListItem - 4
    Metadata.CustomMetadata - 4
    Metadata.ConsoleComponent - 4
    WaveTemplate.VisibilityEnum - 3
    UserProvisioning.CollectingBatchable - 3
    Reports.FormulaType - 3
    Reports.CsfGroupType - 3
    Reports.BucketType - 3
    Process.SparkPlugParameter - 3
    Process.SparkPlugApi - 3
    Metadata.PlatformActionList - 3
    Metadata.FeedLayoutFilter - 3
    Metadata.FeedLayoutComponent - 3
    ApexPages.ComponentIteration - 3
    VisualEditor.DesignTimePageContext - 2
    Metadata.SubtabComponents - 2
    Metadata.RelatedList - 2
    Metadata.PrimaryTabComponents - 2
    Metadata.MiniLayout - 2
    Metadata.LayoutColumn - 2
    Metadata.DeployDetails - 2
    Metadata.CustomMetadataValue - 2
    Metadata.CustomConsoleComponents - 2
    Messaging.InboundEnvelope - 2
    Messaging.InboundEmailResult - 2
    EventBus.TriggerContext - 2
    Workflow.Context - 1
    System.Continuation - 1
    Support.Org62LEXFeedbackController - 1
    Schema.DescribeFieldResult - 1
    Process.PluginResult - 1
    Process.PluginRequest - 1
    Metadata.RelatedContentItem - 1
    Metadata.RelatedContent - 1
    Metadata.QuickActionListItem - 1
    Metadata.QuickActionList - 1
    Metadata.Metadata - 1
    Cache.Session - 1
    Cache.Org - 1

    Some of these are almost certainly correct as type Object, but most are particular in those in classes with high counts.

    I'm still trying to decide if I just bite off adding explicit corrections for these during OST generation. As noted above, ideally Salesforce provides a proper fix. I think it just depends on how long that takes...

  4. Scott Wells repo owner

    Doug, I just looked at what you posted again and am not sure I understand. What's missing/wrong in ApexPages.PageReference? Sorry if I'm missing the obvious...

  5. Doug Ayers reporter

    Thanks for the details, Scott.

    Regarding ApexPages.PageReference I meant that IC2 gives the same "cannot resolve symbol" error. I've re-generated a full OST twice and ApexPages.PageReference doesn't exist.



  6. Scott Wells repo owner

    Ahhhhhh....I see. So here's what's strange....according to Salesforce, PageReference is in the System namespace:

    and it's not in the ApexPages namespace at all:

    Having said that, ApexPages.PageReference is still accepted by the Apex compiler, but it's not reported by the API that's used to build out the system types portion of the OST (the Tooling API's completions REST resource).

    I'd prefer to keep that issue separate from this one as it's categorically different. I'll log another bug shortly on the topic, and I want to follow up with Salesforce as to how it should be handled. I'm not sure whether to stub out the ApexPages version for development, tell folks to start using the System version instead, or what.

  7. Doug Ayers reporter

    Well that is interesting. Strange that it lets the code compile and run with ApexPages namespace. A google search and I find code samples, even on Salesforce's own blog posts, that will use ApexPages.PageReference. Strange indeed!

  8. Elie Hassan

    I've just started leveraging dml options more heavily in my org, and I am running into this issue as well. Is there any update as to if a fix for this is possible and where it falls on the roadmap?

    Screen Shot 2018-10-23 at 3.01.30 PM.png

  9. Scott Wells repo owner

    I spoke with the Salesforce Tooling team at length about this while at Dreamforce this year. They know the root cause of the issue, but evidently it's more complex than expected because of how they assemble the set of system Apex types from various teams/products. Let me follow up with the primary person who was going to look into this and see if he has any update to provide.

  10. Elie Hassan

    Is there any way to ignore an issue like that if the class saves to the server and compiles correctly (which is a clear indicator that it's a false error)?

  11. Scott Wells repo owner

    Partial fix delivered in and for IC2 and IC1 respectively. After updating and regenerating your OST, all properties in Database.DMLOptions should have proper type information. I'll look at updating other system types that are missing type information in future updates based on prevalence of usage. The Metadata namespace is a key candidate, but I'd love to hear from users about what else might be most useful.

  12. Scott Wells repo owner

    In, all instances of this issue in the Messaging namespace have been addressed.

  13. Justin Julicher

    Hi Scott, not sure if this is totally related but custom metadata relationships are not coming through properly (coming through as Strings rather than SOBjectTYpe.


    so when you select or use it it looks like:


  14. Scott Wells repo owner

    Sorry, Justin. Playing catch-up. That's not likely related to the problem in this particular issue. What I'll likely need you to do is enable debug logging for OST generation, generate the SObjects portion of your OST, and provide the resulting idea.log* files from the span of time during which the OST was generating. Feel free to email that to me for review.

  15. Scott Wells repo owner

    This will be pretty much resolved in the next build. Missing classes such as those in the DataSource namespace will be present, and all properties in the OST should be strongly-typed with the notable exception of those in ConnectApi namespace classes. That's because there are SO MANY of them with SO MANY properties, and they're just not very well-documented. I've addressed many of them, but there are many more in that namespace that are not addressed.

    Once I publish the next build, you'll need to regenerate your OST to pick up the changes.

  16. Scott Wells repo owner

    Delivered in

    Issue 821 - I finally broke down and filled in the gaps in the OST around system types that either aren't included in the Tooling API completions resource or are included with untyped properties. The one notable exception is the ConnectApi namespace which was updated as much as possible given the limited documentation available, but many properties still lack type information. Otherwise all properties should now be strongly-typed, and the totally missing DataSource namespace types should now be present and accurate.

    NOTE: You must regenerate your offline symbol table to pick up these changes.

  17. Log in to comment