Can't Refresh or Retrieve Metadata

[Jason Curry]

Since updating to 1.8.0.4 this morning I can no longer refresh or retrieve meta-data from the server. It was working perfectly yesterday before the update. Is happening on all of my projects.

Error

Argument for @NotNull parameter 's' of com/intellij/openapi/util/text/StringUtil.split must not be null

IntelliJ IDEA 2017.2.5 Build #IU-172.4343.14, built on September 26, 2017 JRE: 1.8.0_152-release-915-b12 x86_64 JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o Mac OS X 10.12.6

[Scott Wells]

So sorry for the issue, Jason. Can you send me your idea.log (Help>Show Log in Finder) so I can see the stack trace?

[Scott Wells]

Thanks, Jason. If you don't mind, would you do it one more time with the following in Help>Debug Log Settings:

#com.illuminatedcloud.intellij.builder.ForceComMetadataRetriever

That will give me considerably more information about what's being passed to that method that's null so I can turn around a quick fix.

[Jason Curry]

With Debug Log setting: #com.illuminatedcloud.intellij.builder.ForceComMetadataRetriever

[Jason Curry]

Found a project where the refresh is working. The main difference between the projects, the ones that fail have Aura/lightning component.

[Scott Wells]

Jason, I believe the issue is due to this:

2017-10-04 16:55:44,825 [  52989]  DEBUG - lder.ForceComMetadataRetriever - projectRoot = /Users/jason/IdeaProjects/WS Dev - Opfocus1 
2017-10-04 16:55:44,825 [  52989]  DEBUG - lder.ForceComMetadataRetriever - mainSourceRoot = /Users/jason/projects/opfocus/WS Dev/Opfocus1/src 

Your source root is not a child of the project root. I'm actually surprised that ever worked, but in support of SFDX I had to retool some things around matching of retrieved/pulled metadata against the local versions of the same files. You'll need to restructure your project so that the project root is an ancestor of all source roots. That's why this is happening (though it could obviously be handled more gracefully).

[Jason Curry]

I deleted the projects, and the IC records under SDKs and recreated them. Everything with those projects appears to be working better now.

[Jason Curry]

Fully deleting the project out and recreating them worked. Also needed to remove the project link from the Project Structure/SDKs was needed.

[Scott Wells]

Thanks for letting me know, Jason, and sorry for the issues. I'll improve the reporting around that situation to make it easier to understand when/why this is happening.

[Scott Wells]

Another user reported a related problem so I dug in a bit. This test build will hopefully resolve the general class of issues. I'm going to let the other user know about it as well to get a little validation testing before releasing it in the official build.

[Scott Wells]

Issue #735 was marked as a duplicate of this issue.

[Scott Wells]

Updated test build that prompts the user to select a default source root when a module has multiple source roots. I'll plan to release this as the official build no later than Monday.

[Scott Wells]

Delivered in 1.8.0.5. If you're still seeing any form of this issue after updating please let me know ASAP so that I can address it.

[Daniel C.]

Hi Scott. Thanks for pointing out a fix for this. I do have a scenario where I need two different folders: 1 for the project root (to store the project-specific settings) and the default source root to point to the local git repo. For example:

2017-10-10 23:41:48,626 [4037586]  DEBUG - lder.ForceComMetadataRetriever - projectRoot = C:/daniel/workspace/intellij/SF Code - DEV 
2017-10-10 23:41:48,626 [4037586]  DEBUG - lder.ForceComMetadataRetriever - defaultSourceRoot = C:/daniel/workspace/intellij/SF Code - GIT/src

In this scenario, "SF Code - DEV" holds the offline symbol table and the .idea holds the xml settings, while "SF Code - GIT/src" stores the actual project tree and the local GIT repo. When I use other sandboxes, I leverage a different project root but always point to the same git repo to keep the git branches pointing to the same instance. Do you know if the solution proposed is the only way to remedy this error?

Using updated version 1.8.0.5 Thanks for your feedback.

Daniel C.

[Scott Wells]

Daniel, I apologize but I'm not sure I follow the question. I'll repeat back my understanding but please let me know where I'm missing the key details. Basically I think you're saying that you want multiple projects to be able to point to the same source root, each with their own .idea files and OSTs. That way you don't have to pay the tax for switching back and forth as you switch branches. Is that correct? I'll continue as if that's the case, but I'll try not to get long-winded just in case it's not...

What you're having to do is (I think) a workaround for another issue logged in #423 where switching connections is cumbersome right now in IC. I see this often as well when I switch branches and branchA is against orgA while branchB is against orgB. IC currently requires me (or at least nags me insistently!) about orphaned OSTs and needing to generate other OSTs in order to have a whole project. Then I switch back and have to do the same thing all over again. Ideally I'd just be able to have branchA checked in referencing orgA including its generated OST, and similar with branchB, and IC would be just fine with both of those being present in my filesystem. The config files that reference those connections/OSTs would be checked in and would switch back-and-forth as I change branches.

And that's exactly what I plan to do...allow that. And to make it even more convenient, if you switch from branchA/connectionA to branchB/connectionB where connectionA had a generated OST but connectionB did not, prompt you to copy or move that OST so that it can be used by the new connection without having to generate a new one since very often the generated OST is virtually identical between two branches of the same code or connections populated using the same code.

So let me know if that would address your concern or not. If it would, let's track that in #423. If it wouldn't, please let me know how I've misunderstood your requirements so we can figure out how best to capture them in the issue tracker going forward.

[Tetiana Rybalska]

Hi Scott

I have the same error when try to refresh metadata.

[Scott Wells]

Tetiana, can you please update to 1.8.0.6 (posted just a few minutes ago) and see if it resolves the issue for you? Please let me know the results after updating either way. Thanks!

[Tetiana Rybalska]

updated. still have the error

[Scott Wells]

Bummer. Do you mind attaching your a log with the debug details as requested in the first few comments of this issue so I can see what variants of this issue still remain?

[Scott Wells]

Thanks, Tetiana. Would you mind also enabling debug logging as described in the third comment above and then reproducing the issue/log? That should help me understand exactly what's happening. Thanks!

[Scott Wells]

Sorry...the leading # is required. The entry in Help>Debug Log Settings should look exactly like:

#com.illuminatedcloud.intellij.builder.ForceComMetadataRetriever

Mind producing one more log with that? Thanks!

[Tetiana Rybalska]

my fault

[Scott Wells]

Ah, okay. Yeah, you're hitting the same issue hit by Jason, the original poster here. Your project root is not an ancestor of your source root:

2017-10-11 12:43:18,049 [  79282]  DEBUG - lder.ForceComMetadataRetriever - projectRoot = D:/Storage/AO.dev 
2017-10-11 12:43:18,049 [  79282]  DEBUG - lder.ForceComMetadataRetriever - defaultSourceRoot = D:/Storage/Tanya/IlluminatedCloud/src 

Right now that's not supported. As mentioned above, I'm quite surprised that actually worked in earlier builds. Now that I'm seeing multiple people running into this, though, I should probably support it. Otherwise I feel like this is going to become a recurring theme.

To get going now, all you need to do is restructure your project so that the source root is a child or descendant of the project root. However, I think I'm going to look at fixing this completely in the next couple of days just to put the potential recurring issue to rest.

Let me know if that workaround doesn't take care of it for you until I can produce first-class support for this type of project config.

[Tetiana Rybalska]

thanks. I'll try

[Scott Wells]

I'm also going to go ahead and bite the bullet and get this configuration working. Obviously use the workaround to keep from being blocked, but hopefully I'll support your current configuration very soon if that's something you'd really prefer to use.

[Tetiana Rybalska]

thank you. it works.

[Scott Wells]

Glad to hear, but sorry to force you to make such a change. Over lunch I implemented support for source roots not under the project root. I want to test it quite a bit before releasing it, but I'll plan to include it in the next official build. At that point if you want to return the previous folder structure, you'll be able to do so.