OST Entry for Packaged object incorrect when name matches system object name

[Jason Clark]

I’m seeing this with DocuSign App Launcher classes (namespace dfsle, v5.6), but I suspect this is not specific to DS.

Here’s some code that’s basically right out the DS Docs. The withDocuments method of dfsle.Envelope takes a List<dfsle.Document> as a param (DS Doc Link), but the OST thinks it wants a List<Schema.Document>:

‌

The code compiles and executes just fine, but IC shows an the error above. The OST class for dfsle doesn’t have namespace prefixes where needed:

global class /*dfsle.*/Envelope 
{
    global List<CustomField> customFields { get; }
    global List<Document> documents { get; }
...
    global Envelope withDocuments(List<Document> documents)
    {
    }
...
}

This is only a problem where the local name of the namespaced object (dfsle.Document) matches the local name of a standard object (Schema.Document). All other methods work fine.

[Scott Wells]

Jason, before I go through the motions of creating a managed package with a class that matches/conflicts with one of the standard Apex types/SObjects so that I can install it into another org and generate an OST against it, are you perhaps able to provide access to such an org? It could, of course, just be a scratch org with this package installed and otherwise empty. No issues if you can’t, but I figured I’d ask as that would certainly save a non-trivial amount of time and effort when trying to reproduce/fix this.

[Jason Clark]

Yes, let me repro in a scratch org and I’ll email you the org creds.

[Jason Clark]

Well, that didn’t work. I spun up an empty scratch org, installed the dfsle package, and copied the class that exhibits the issue from my customer’s org; no errors are shown. The OST class looks identical. There must be something else going on in my main project. I tried a full OST rebuild in the problem org, but no change in results.

Unfortunately, it is a customer org for which I cannot provide access. And since I cannot provide a simple repro in a clean org, I don’t think there’s any point in you going through all the steps either. Guess we can close this, and I’ll reopen if I ever get a reliable repro. Thanks for the quick response.

[Scott Wells]

Hmmm…so you’re saying that in a clean, standalone project with the package installed, references to the packaged Document type are properly resolved? It’s only in the more complex project that the issue occurs? If so, yeah, it would be good if you could figure out how to distill a reproduction of the issue into the standalone environment, perhaps by stubbing out the required signatures and such that seem to lead to it. Once you can repro it in such an environment, please give me access to that environment and I should be able to figure it out. No need to close this issue immediately, though. Let’s see if you can isolate a reproduction first.

[Scott Wells]

Jason, does this still happen with the latest build? I made some small changes to how potentially ambiguous types are resolved and think it might(/should?) have addressed what you were seeing.

[Jason Clark]

I’m running IC2 v2.3.0.8, and this issue appears to be fully resolved. I’ve checked every place in the codebase where I use a method that accepts a List<dfsle.Document>, and I can no longer reproduce. I think it may have been resolved in 2.3.0.6 as well; I don't recall seeing this issue before updating. Thanks!

[Scott Wells]

Issue tracker grooming.