Unable to use deploy/retrieve dialogs after update

[Xander Victory]

Clicking the Deploy All Metadata or Retrieve Metadata toolbar buttons pops up a dialog with the exception message (seems to not actually be logged each time or my log hasnt flushed properly even after a restart).

SFDX format project connected to a sandbox org (no scratch nor packaging).

• IJ-U 2023.1.2
• IC2 2.2.7.2

2023-06-13 11:10:44,087 [ 180190]   WARN - #com.illuminatedcloud.util.IlluminatedCloudExceptionUtil - Argument for @NotNull parameter 'subDirName' of com/illuminatedcloud/intellij/builder/BuildOptionsCheckboxTreeNode.<init> must not be null
java.lang.IllegalArgumentException: Argument for @NotNull parameter 'subDirName' of com/illuminatedcloud/intellij/builder/BuildOptionsCheckboxTreeNode.<init> must not be null
    at com.illuminatedcloud.intellij.builder.BuildOptionsCheckboxTreeNode.$$$reportNull$$$0(SourceFile)
    at com.illuminatedcloud.intellij.builder.BuildOptionsCheckboxTreeNode.<init>(SourceFile)
    at com.illuminatedcloud.intellij.builder.BuildOptionsDialog$2.run(SourceFile:1536)
    at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:429)
    at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:114)
    at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressSynchronously$9(CoreProgressManager.java:513)
    at com.intellij.openapi.progress.impl.ProgressRunner.lambda$new$0(ProgressRunner.java:84)
    at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:252)
    at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:186)
    at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:604)
    at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:679)
    at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:635)
    at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:603)
    at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
    at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:173)
    at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:252)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
    at java.base/java.lang.Thread.run(Thread.java:833)

‌

[Scott Wells]

Xander, it’s quite late here so I don’t want to rush anything, but a question and a suggestion.

First, the question…the NPE is occuring when it sees that a local metadata file’s path includes a slash (/) and therefore appears to be foldered. Do you have any foldered metadata that is not under the respective metadata type-specific directory? That seems to be what would lead to this issue.

Now the suggestion. If this is keeping you from getting work done, you can revert to the previous version here:

https://plugins.jetbrains.com/plugin/10253-illuminated-cloud-2/versions/stable/344840

I’m obviously still going to want to fix this issue ASAP, but I’d like to understand it better and ideally reproduce it locally so I can fix the actual issue. Any information you can provide about the local metadata file(s) causing the issue including their filesystem path placement would be greatly appreciated.

[Scott Wells]

Actually I'll try to do one better than that. Here's a build of 2.2.7.2 with some defensive behavior around the failure. It should no longer fail, and in this particular situation, it should log something like:

Failed to extract the metdata directory-relative path from '<path>' where the expected metadata directory is '<name>'.

If you don't mind, please install this build using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu), then try to reproduce the issue. It shouldn't fail any longer, and your idea.log should include the aforementioned message. Do you mind providing that?

If for any reason it does continue to fail, you can always drop back to 2.2.7.1, but please let me know if you've had to do that.

[Xander Victory]

That has indeed allowed things to work again (I had indeed downgraded to complete my work)

2023-06-13 13:13:25,255 [ 204632]   WARN - #com.illuminatedcloud.intellij.builder.BuildOptionsDialog - Failed to extract the metadata directory-relative path from 'main/default/reports' where the expected metadata directory is 'reports'.
2023-06-13 13:13:25,256 [ 204633]   WARN - #com.illuminatedcloud.intellij.builder.BuildOptionsDialog - Failed to extract the metadata directory-relative path from 'main/default/dashboards' where the expected metadata directory is 'dashboards'.
2023-06-13 13:13:25,264 [ 204641]   WARN - #com.illuminatedcloud.intellij.builder.BuildOptionsDialog - Failed to extract the metadata directory-relative path from 'main/default/documents' where the expected metadata directory is 'documents'.

The mentioned folders do have files in them.

The project does have multiple source roots inside the force-app directory though.

‌

[Scott Wells]

I’m unable to reproduce this locally. I’m probably going to issue a hotfix anyway since you’ve confirmed that it resolves the issue for you, but can you please describe these foldered metadata type directories? What are their respective source roots in the project? Are all of their contents under folders? I’ve tried quite a few things and haven’t yet gotten it to see the raw dashboards/documents/reports metadata type folders as what seem to be metadata itself.

[Scott Wells]

Delivered in 2.2.7.3.

[Scott Wells]

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

[Xander Victory]

There are the following matching named directories in the project folder:

./node_modules/sfdx-cli/node_modules/@salesforce/templates/lib/templates/analytics/waveTemplates/DefaultAnalyticsTemplate/dashboards
./node_modules/@salesforce/cli/node_modules/@salesforce/templates/lib/templates/analytics/waveTemplates/DefaultAnalyticsTemplate/dashboards
./force-app/datamig/default/dashboards
./force-app/datamig/default/reports
./force-app/nebula-logger/core/main/log-management/reports
./force-app/main/default/dashboards
./force-app/main/default/documents
./force-app/main/default/reports

‌

Not all the directories seem to be detected as module(?) roots (though main is):

‌

Looking at dashboard and reports, some have a folder inside, but main is just non-nested report/dashboard files

‌

Documents has a folder as well as 2 .documentFolder files (no corresponding folder)

[Scott Wells]

Got it. The items under node_modules aren’t going to be picked up as content/source roots because they’re automatically added by the IDE as a library. The others should be picked up as long as they’re specified as/under packageDirectories in the project’s sfdx-project.json file. Otherwise you’d need to add the content/source roots manually.

Regarding “but main is just non-nested report/dashboard files”, are you saying that those are stored as reports/reportName.report-meta.xml with no folder, or are you saying that they’re not under a reports directory at all? If the former, I don’t think that IC2 is going to pick them up as I think it currently expects foldered metadata types to include at least one level of folder above the actual metadata files. Sounds like that may not be correct, though? If the latter, I don’t think that’s valid. I’m pretty sure that even in more flexible source format projects, those are among the metadata types that must be under their reported metadata type directories (others include aura, lwc, staticresources, etc., because those (can) present as bundles).

Sounds like there may be one gap identified here if reports/dashboard/documents can exist not under a folder and IC2 isn’t properly supporting that at the moment.

[Xander Victory]

Apologies, they have just reportFolder metadata files in the main reports folder.

‌

The sfdx-project just lists the force-app, I’m not sure this is correct or not? (it’s a git based project so this was set up before I started)

"packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],

‌

[Scott Wells]

Nope, everything you’ve described is perfectly fine. Hopefully you’re not seeing any further issues with how you have it laid out on disk now, correct?

[Xander Victory]

Yeah no issues since the hotfix