Knowledge article version sObject not being indexed for code completion

[Michael Richmond]

Illuminated Cloud: 2.2.0.5

WebStorm: 2021.3.2

I have an odd situation where some Knowledge article sObjects are being inserted into the OST, but are not indexed for code completion.

‌

I’ve attempted to rebuild the cache (Illuminated Cloud > Configure Project > Rebuild Caches and Indices), rebuild the entire OST (Illuminated Cloud > Generate Offline Symbol Table > Full), and started a new project. All end up with the sObject not resolving.

I have also tried this against multiple environments with the same result.

There were no errors in the log, but I couldn’t find any debug log settings for indexing, just OST generation (which appears fine).

Any ideas?

[Scott Wells]

Michael, can you please try to use File>Invalidate Caches to rebuild all IDE caches and indices and let me know if that doesn't work?

[Michael Richmond]

Hi Scott,

Yeah, same thing happens.

The odd thing is that not all Knowledge Article objects are affected, but the ones that don’t work are all Knowledge Article objects.

Thanks,
Michael

[Scott Wells]

Any chance you can either send me that generated OST or, even better, an entire skeletal project against that OST with a sample Apex class that reproduces the issue? Understood if not, but that would be the fastest path to figuring out what's going on. You're welcome to email it to me vs. attaching it here if you'd prefer.

[Michael Richmond]

I would like to avoid having to send the entire OST. Is there another option to troubleshoot?

[Scott Wells]

Along those lines, if you could create a new generally empty project that includes a KAV that exhibits the same behavior. That would ensure you're not having to send any proprietary info but would provide a reproduction of the issue.

[Michael Richmond]

How do I provide you with a project that does not have a full OST generated?

[Scott Wells]

There are two ways you can go here:

1. You can create a brand new project against a clean scratch org, create simple Knowledge Article/Version objects in that org, and create a simple Apex class that references those where the references don't resolve. In this option, you can provide the entire project including the OST because it will have been against a clean scratch org.
2. You can do all of this against your existing project but then just cherry pick what you add to an archive to provide me. I'd primarily just need to the ka and kav files and the Apex class that references them but not the OST because I'd just deploy those against a scratch org, generate my own OST, and try to reproduce this behavior.

Make sense? Let me know if not.

[Michael Richmond]

Thanks Scott.

I was able to reproduce on a scratch org, and have sent you the project over email.

[Scott Wells]

Thanks, Michael. Easily reproduced with the provided project. I'm pretty sure it has to do with the base names Process and Support which are also namespaces, and I'm thinking IC2 is interpreting Process__kav as type kav in the Process namespace (and similar with Support). Should be easy enough for IC2 to filter the known extensions of various SObject types when doing that analysis. I'll put a fix together and include it in next week's build.

[Michael Richmond]

Thanks Scott!

[Scott Wells]

Yep, it was exactly what I thought. About to commit the fix:

I'm really surprised this is the first time this one has come up over the years. I have to assume that others have named some kind of custom object with the same base name as a namespace and just didn't report it. Anyway, the fix will be in next week's build.

[Scott Wells]

Ah, I see. IC2 was already taking this situation into account, but it wasn't including the __ka and __kav extensions (also __b). I just changed my fix to include those extensions and the world is a happy place without having to change any real existing logic...just the set of known custom object extensions. That explains why I hadn't heard about this until now.

[Michael Richmond]

Yeah that makes more sense, because we do have some objects would have already conflicted with other namespaces, and they were not an issue.

Glad it was an easy fix!

Thanks again Scott.

[Scott Wells]

Delivered in 2.2.0.6.