Code inspection false negatives - Namespace flavor!

[Chuck Liddell]

Note: I'm running 2.0.0.2, but that's not currently a version I can select in the metadata for this bug report.

I see that you're stamping out false negatives left and right with code inspection.

I did not see a bug already reported on false negatives related to namespaces. My codebase lit up like a Christmas tree (see what I did there?) when I moved to IC 2.0. Here's a sneak preview of what I'm talking about:

I have thousands of false negatives, but I'd bet they're all coming from a fairly small subset of reasons. Note that this code base works fine.

Unresolvable reference: 5,136 errors reported. Illegal assignment: 80 errors reported.

My guess here is that the inspection tool is not handling namespaces correctly in certain circumstances.

Context: I'm developing a managed package using scratch orgs, so each scratch org is created with a specific namespace that matches the managed package namespace. Let me know if you need to see the sfdx-project.json.

Here are some of the varieties of false negatives I'm seeing:

Scenario One - Unresolvable reference at class level

if(!(pullAdapterInstance instanceof SourceAdapterForSObjectPush))

Highlights SourceAdapterForSObjectPush in red.

If I change the code to this:

if(!(pullAdapterInstance instanceof valence.SourceAdapterForSObjectPush))

No more red. SourceAdapterForSObjectPush is a global interface, so subscribers of the package would indeed have to prefix the class name with the namespace, but inside the package I don't have to use the prefix.

Note: Don't be mislead by the global thing. This happens for public classes in the codebase as well.

Scenario Two - Unresolvable reference at class property level

I'm getting a bunch of unresolvable class instance properties, but from my testing these are happening because the class they belong to is unresolvable, and when I prefix that class reference with the package namespace the property references stop being cranky.

I wouldn't be super surprised if there is some kind of reference problem between global / public class properties, because public should be resolvable from inside the managed package but not outside it, and the gist of what I'm seeing makes me think that the inspector is looking at all my code through the lens of not being inside the package.

Scenario Three - Illegal Assignment from namespaced class to same class non-namespaced

LinkRepository.Link link = LinkRepository.getByName(linkName);

Code like the above is reported as an illegal assignment, and shouldn't be.

"Illegal assignment from valence.LinkRepository.Link to LinkRepository.Link."

Here's the signature of that method on LinkRepository:

public static Link getByName(String name);

This doesn't only happen with inner classes, by the way:

Table testTable = Table.create('tableName').build();

"Illegal assignment from valence.Table to Table"

[Scott Wells]

Chuck, my main day-to-day project is against namespaced metadata and I don't see this, so hopefully it's just a simple configuration issue that wasn't critical in IC1 but becomes critical in IC2 due to the deeper code analysis that's happening.

Can you verify that the namespace for the connection to your organization is properly set to valence? You would see this in the connection settings as the value for Organization Namespace. If memory serves, you guys are 100% SFDX now, so this value would be derived from sfdx-project.json.

Once that's set properly, should associate that namespace as the "local" namespace for all modules configured for the connection. References to symbols in that namespace from within those modules won't require explicit namespace qualifications. Given that adding an explicit namespace qualification clears up these issues for you, I feel confident that's the root of what you're seeing.

[Scott Wells]

FYI, I'm playing with this in SFDX and am seeing what appears to be an issue. Hopefully I'll figure it out very shortly and can include the fix in the next build.

[Scott Wells]

Hmmmm...actually what I thought was an issue wasn't. Can you confirm that your namespace is set properly in the org and in the sfdx-project.json? It appears that if it's set in both places, everything seems to work correctly. Given that the source saves properly with and without namespace qualifications, my guess is that it's set in the org, so perhaps the JSON setting is what's missing for you.

[Scott Wells]

Chuck, I did take a look at this today with an SFDX scratch org configured for a namespace. So far I'm unable to reproduce the issues you're seeing, so I'm back to thinking it's either a configuration issue or perhaps some minor bug.

For reference, here's what I did to try to reproduce the issue:

1. I already had a DE org with a namespace that I've used for namespace testing of IC in the past, so I just linked that org into my dev hub to allow me to use the namespace in scratch orgs. The namespace is base_dev.
2. Created a new SFDX project in IC with the namespace base_dev via IC.
3. Created a new scratch org for the new project via IC.
4. Converted the source for my MDAPI project for the base_dev namespace to SFDX form for the new project via the CLI.
5. Pushed the converted source to the new scratch org via IC.
6. Regenerated the OST for the project now that the source had been deployed.

With that done, I see the SObjects correctly rendered into the OST in the base_dev namespace:

and I'm able to reference the contents of the project with and without namespace qualifications without triggering any code inspection false negatives:

It's also worth pointing out that the connection properly shows the namespace (I think yours did not):

as does the project configuration (I think yours did):

You might try clicking the Test button in the connection config and see if that causes IC to fetch the namespace from the org and use it correctly. If it does, I'd recommend you then regenerate your OST to make sure that things end up in the correct namespace and see if that doesn't help.

Let me know whether this info helps to isolate and/or correct the issue or not, and of course if there's something you've done differently from what I've described here, let me know.

[Scott Wells]

Chuck, any update on this? If you've managed to get things set up as described above and it's still not working...or if you couldn't get it set up as described above...let me know.

[Scott Wells]

Chuck, I'm assuming/hoping that you're past this issue based on the info I've provided and am resolving this. If you're still seeing the issue, definitely reopen it and we'll work through it.

[Philipp Ortner]

Hello,

Our team has the exact same problem.

Already checked what you told Chuck here, Official Namespace, Namespace in the sfdx-project.json and the Namespace in the connection are all correct.

The Namespace folder in the OST is present and seems to hold all the required information but if I don't prefix every such class with the namespace I get the can't resolve the symbol error.

We also checked if the namespace is linked correctly to the scratch org in the Scratch Org Infos related list in our DevHub Org.

Any help with this would be greatly appreciated.

[Chuck Liddell]

@PhilippOrtnerUp2Go I did eventually solve this one, and it was a misleading little devil.

What ended up being the problem was I was generating a deploy folder of converted metadata inside my project folder, and this was confusing the crap out of Illuminated Cloud because I essentially had two entire sets of metadata files sitting in my project folder.

For clarity, I was running "sfdx force:source:convert --outputdir mdapi", and once I did this tons of errors would show up. All I had to do to fix was delete the "mdapi" folder I had generated.

[Philipp Ortner]

@grekker thanks for the update!

I've had those in my path too but my deployment script deletes these folders after it finishes so it's definitely gone.

Tried regenerating the OST a few times and tried it in new scratch orgs, never having a converted folder when doing this.

Still could be something related to this, I'll try some more things.

Thanks again for the info

[Scott Wells]

Philipp and Chuck, I've had a couple of other folks report this to me in the last day or so, all using SFDX, where the namespace isn't being picked up properly from the sfdx-project.json file and as a result it's mishandling namespace qualifications during completion and reference resolution. I tried to reproduce it last night unsuccessfully. I'll continue to do so until I get it nailed. I may need to reach out to you, Philipp, for additional info as I try to reproduce it. I'll go ahead and reopen this issue to track progress and redirect the others reporting the problem here so we're all working together toward the same goal of a fix.

[Philipp Ortner]

@RoseSilverSoftware Awesome, thanks for the support. Will help whenever I can.

[Patryk Organa]

Hi Guys, sorry for delay, Scott this is screenshot of my connection config:

I found something interesting, recently I activated my Intellij ultimate, and everything seems to be fine now, custom types even without namespaces are correctly recognized. For me it looks like this issue can be related to Intellij version Ultimate vs community, because I didnt do any other changes in connectio0n, config etc. If I remeber correctly I was even not rebuilding OST after switching to Ultimate.

Hope it will throw a little more light on this.

[Scott Wells]

Hmmmm...so I'm glad it's working for you, but I'm skeptical that it's a difference between UE and CE. The main differences there are around how JavaScript and CSS are handled. All of the Apex stuff should be identical. My guess is that by changing out IDEs, you also forced a full rebuild of caches and indices which put something right. Let me know if you do see this issue again.

[Scott Wells]

This should also have been resolved a bit back when I changed IC2 to use the actual org/connection namespace and not the one in sfdx-project.json.