Coverage isn't displayed properly after running tests for coverage

[Scott Wells]

I've heard about this from one user and we're having trouble pinpointing why it's happening. I'm using this both to track the issue toward resolution and to provide a pre-release build with some additional diagnostic logging.

[Scott Wells]

This build includes additional debug logging around the logic that results in that loading dialog that seems to pop up twice for you. Let's see if this helps to pin down what's going on.

[Jason Pate]

Scott I installed the zip. I didn’t see any difference. This is what I still get. The first image comes up, then the loading coverage. It finishes and then I have to click ok 3 times. Still not coverage.

‌

‌

‌

‌

[Scott Wells]

Hi, Jason. That build doesn't include a fix. It includes more diagnostic logging to try to corner the behavior so I can "see" it in action and figure out how to accommodate. You can enable that debug logging by adding the following to Help>Diagnostic Tools>Debug Log Settings:

#com.illuminatedcloud.intellij.coverage.ApexCoverageAnnotator

Then reproduce the behavior and attach the resulting idea.log (found using Help>Show Log in Explorer).

[Jason Pate]

Here you go

• Logs: IdeaLog

‌

[Scott Wells]

Hi. Thanks for the log, Jason. Did you happen to set up debug logging as described in the previous comment here? I'm not seeing any debug logging output from that class in the provided log file.

[Jason Pate]

So I unzipped the files into my installation directory and put this into the debug config. Then I ran it. Is that correct? I’m running it again now and will re-attach the log

‌

‌

[Jason Pate]

Same link as above to the log

[Scott Wells]

WORKAROUND: For those having this issue, you can use Illuminated Cloud > Show Coverage Data... after this problem occurs to show the desired information. Hopefully the need for that workaround will be short-lived.

Unfortunately the provided logs don't include the needed information, and I'm still unable to reproduce this behavior in any of my own test projects.

I'm attaching a new build here based on today's official build, 2.2.2.8, but with the additional diagnostic logging.

For those of you having this issue, please install this build by downloading the attached archive (it should not be extracted) and using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu).

After the IDE restarts, make sure that the following is present in Help > Diagnostic Tools > Debug Log Settings:

#com.illuminatedcloud.intellij.coverage.ApexCoverageAnnotator

Note that the leading # is intentional and must be retained.

Then reproduce this behavior by running unit tests for coverage and attach all resulting idea.log* file(s) from the timespan of that unit test run. You can find them using Help > Show Log in Explorer / Finder / Files.

It would also be helpful if you could include the following information:

• Which OS you're using
• Which JetBrains IDE you use, both product and version
• Whether your project is source format or metadata format
• Which type of organization you're working against

Hopefully that will help me to gain insights into why this is suddenly happening to some of you so that I can provide a proper fix. Thanks in advance!

[Jason Pate]

• Which OS you're using - Windows 10 Pro
• Which JetBrains IDE you use, both product and version 2022.1.3 Build #IU-221.5921.22, built on June 21, 2022
• Whether your project is source format or metadata format
• Which type of organization you're working against

‌

[Jason Pate]

idea.log

[Scott Wells]

Thanks, Jason. To quote U2, though, I still haven't found what I'm looking for. Not due to anything you did or didn't do...it just looks like my best guess on where this might be happening was incorrect as the instrumented code isn't being executed, hence no additional diagnostic logging.

Okay, in the interest of trying to get to the bottom of this quickly, does anyone have an org against which this happens that I could connect to directly? Ideally that would be a scratch org with a completely standalone set of non-proprietary metadata that results in this behavior. If you can provide that, feel free to reach out to me directly to coordinate providing access.

The issue is that so much of the handoff from unit test execution to code coverage display happens pretty deep in the base JetBrains IDE where I can't really instrument additional debug logging, so without being able to reproduce this locally where I can connect a debugger, it's going to be very difficult to corner this behavior. Of course, it's always possible--perhaps even likely--that the org isn't the key variable and it's something about the local IDE install in which case I wouldn't even be able to reproduce it that way, but right now that seems like the next best option as minimally it would help to identify or eliminate the org as a variable.

[Jason Pate]

Scott, no worries. I am up for a PC refresh anyway so i’ll just re-install both Intellij and Illuminated cloud when that arrives. My guess is that during one of the updates something caused this. I don’t remember which update.

[Attila Hajdrik]

Currently coverage information is visible only on “Code” designated nodes. In my project I’ve the structure you can see on the image. 01-core, 02-common, 03-address-verification are folders in sfdxproject.json. Would it be possible to not just show coverage on main folders nested, but on the project folders as well?

‌

[Scott Wells]

@Attila Hajdrik , do you mind breaking this out into its own enhancement request since it’s not directly related to the original issue tracked here? I’m not sure if it’s possible to annotate intermediate directories in the project view with their own percentage breakdowns, but I’d certainly be happy to investigate that.

[Attila Hajdrik]

Done: #2192

[Donna Vincent]

Scott,

I have been experiencing this also. I noticed it when generating a coverage report. All of the lines show as red, but if I I run “Show Coverage Data” and then run the coverage report, the highlighting appears correctly. I went ahead and add the line for #com.illuminatedcloud.intellij.coverage.ApexCoverageAnnotator

• Windows 11
• Intellij IDEA 2022.2.2 Ultimate Edition, Build #IU-222.4167.29, built on September 13, 2022
• I THINK my project is in source format (I see force-app rather than src)
• I am working against a sandbox
• My version of IC2 is 2.2.3.6 BUILD 2022091510906.

Trying to attach log file. :)

[Donna Vincent]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Donna Vincent]

Scott,

I just checked another project which is metadata format (src in project display) and it has the same issue. not sure if that helps.

Here are other settings from Help → About. Not sure if they will help or not.
Runtime version: 17.0.4+7-b469.53 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 20
Non-Bundled Plugins:
com.jetbrains.darkPurpleTheme (1.3)
com.jetbrains.CyanTheme (1.3)
com.illuminatedcloud2.intellij (2.2.3.6)

Kotlin: 222-1.7.10-release-334-IJ4167.29

‌

[Scott Wells]

Hi, Donna. I’m seeing a large number of entries like this in the provided log:

2022-09-22 13:40:04,868 [14865238]   WARN - #c.i.i.c.ApexCoverageSuite - No uncovered line details found in coverage response for ApexTrigger:HEALTHHISTORYQUETIONTRIGGER when lines uncovered = 4. Adding all executable lines that were not reported as covered as uncovered.

That would explain “all of the lines show as red”, but the log doesn’t show what exactly was returned by the Salesforce APIs that lead to that situation. I’d need to see a log with debug logging enabled to get more insights into that. Can you please enable debug logging for Code Coverage, reproduce this behavior, and then attach a new log that includes the full time frame of the reproduction?

[Tyler Raguseo]

Hi Scott,

I’m also experiencing this issue, here’s a log with debug logging enabled: https://file.io/ocu7DpZ2oXAo

It wouldn’t let me attach anything other than an image.

[Scott Wells]

Thank you, Tyler. Let me digest the provided log a bit and see if I can discern anything from it. One quick thing, though, is that I noticed an exception in the log during OST generation about “Maximum Number of Child Elements limit (50000) Exceeded”. Please see #2063 for a way to resolve that issue when working against an org that can result in very large SOAP responses. I wouldn’t expect that to be a contributor to the test coverage issue at all, but it could result in an incomplete OST which could lead to other issues.

Hopefully I’ll be able to provide any new insights from the log here shortly.

[Scott Wells]

Tyler, I’m seeing multiple test/coverage runs in the log and am having a hard time understanding whether the issue is occurring with all of them, some of them, only the last one, etc. Is it safe for me to look at only the last test run starting at 11:51:57,510 in the log?

[Tyler Raguseo]

Scott, yes it’s safe to look at only the last test run. It’s the same test run a few times, so any/all of them should be the same.

Thanks for the insight on the other issue!

[Scott Wells]

Thanks for confirming. And just to be 100% clear, your experience is that you execute this unit test run configuration, invocableSendTextMessageTest, with coverage, and upon test execution completion it looks like it’s fetching and showing the coverage, but then the coverage either isn’t shown or looks like it’s shown very briefly and then disappears. Is that correct? If not, can you explain the exact behavior you’re seeing that corresponds to that subset of the log?

[Tyler Raguseo]

Yep, I run that test (or any test in this project) it looks like it comes back with freshly fetched coverage data, but when I show the coverage data all lines are marked as uncovered.

If I run the same test in the Developer Console, the lines will all show as covered.

[Scott Wells]

Wait, that sounds different from what (I think?) others here have experienced. The original issue, as I understood it was the following:

1. Run unit tests with coverage.
2. Test execution completes and coverage briefly flashes but then closes.
3. Explicitly executing the Illuminated Cloud > Show Coverage Data action properly shows coverage.

And if I understand you correctly, it sounds like even step 3 isn’t showing the correct coverage results in IC2? Or am I misunderstanding?

[Tyler Raguseo]

Correct, test execution completes and code coverage data appears to be updated, but when I show the coverage data all lines are uncovered.

‌

[Scott Wells]

Okay. Yeah, I think there are two issues now being discussed here, one where coverage is shown only briefly after Run with Coverage but still shows properly via explicit Show Coverage Data (i.e., the original issue), and one where coverage just isn’t being shown properly in IC2 (your issue). If I can’t find a quick solution for yours, we may want to split it off into its own entry in the issue tracker to keep those distinct.

Can you please attach your project’s .iml file here so I can confirm that the content and source roots are configured properly?

[Tyler Raguseo]

Here’s the .iml file: https://file.io/T7ECftjIkKLM

‌

[Scott Wells]

Thanks. So what I’m seeing is that most of your classes and triggers are not found in the project, e.g.:

2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite - Processing line data for ApexClass:SCMLOCATEINVOCABLE
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Getting or creating class data
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Getting the line count
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite - Getting the line count for class/trigger ApexClass:SCMLOCATEINVOCABLE
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Searching for the symbol as a class.
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Failed to find a matching class or trigger.
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Line count = 0
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite - Processing line data for ApexClass:INVOCABLESENDTEXTMESSAGE
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Getting or creating class data
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Getting the line count
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite - Getting the line count for class/trigger ApexClass:INVOCABLESENDTEXTMESSAGE
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Searching for the symbol as a class.
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   Found matching class or trigger: S:/IdeaProjects/DEV WSH/src/classes/invocableSendTextMessage.cls
2022-11-15 11:53:03,564 [9076602]   FINE - #c.i.i.c.ApexCoverageSuite -   File S:/IdeaProjects/DEV WSH/src/classes/invocableSendTextMessage.cls is under source root S:/IdeaProjects/DEV WSH/src.

Notice that INVOCABLESENTTEXTMESSAGE is found as file S:/IdeaProjects/DEV WSH/src/classes/invocableSendTextMessage.cls, but SCMLOCATEINVOCABLE is not found. Where does the file SCMLOCATEINVOCABLE.cls reside in the project (ignoring case as these search are case-insensitive)? Is it under S:/IdeaProjects/DEV WSH/src/classes or somewhere else? If under that directory, please use File > Invalidate Caches and, after the restart and reindex, see if the same problem occurs. If somewhere else, that directory must also be added as a source root in the project.

Please let me know your thoughts and findings.

[Tyler Raguseo]

Invalidating the caches and restarting/reindexing seems to have fixed the issue. Thanks for your time Scott.

[Scott Wells]

Okay. If that happens again, please let me know. There’s no (good) reason for things to get into such a state where it can’t resolve those classes, and frankly I would expect that to cause no end of other issues in the IDE as well. But certainly glad it’s resolved for you. Thanks for circling back to let me know.

[Scott Wells]

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

[Scott Wells]

For those affected by this issue--coverage opening and immediately closing after running Apex unit tests with coverage--I have unfortunately scoured every provided log without finding a useful lead on why it’s happening. I’m also still unable to reproduce this behavior in any of my test environments. But…I absolutely trust that it’s happening and want to help fix it!

At this point the best way for me to get to the bottom of it is going to be capturing it in action, and the easiest way to do that is likely for someone who can reproduce it reliably to connect a remote debugger to their running IDE instance with a breakpoint in the JetBrains code that closes the coverage view and reporting back to me the caller stack trace. This is an unconventional request, I know, and I’m even happy to jump on a screenshare while you do this to help get the required info to figure out the root cause.

If anyone is interested in helping to debug things a bit this way, here’s how you can set up a remote debugger and get this information:

1. If you don’t already have IntelliJ IDEA installed, install IntelliJ IDEA Community Edition. If you use IC2 with IntelliJ IDEA, please install another JetBrains IDE that’s supported by IC2 because two will be needed for this. You could even install a second instance of IntelliJ IDEA if you’d like. It’s just important that there be two running IDE processes, one as the debugger and another as the debuggee. It’s also important that the two IDEs be the exact same version or the line numbers may not align during debugging.
2. In IntelliJ IDEA, make sure that the Plugin DevKit plugin is enabled.

3. Create a new project using the New Project template:

   • Name - ic2_debug
   • Location - Up to you
   • JDK - Choose or download a Java 11 JDK; we’re going to replace it below anyway
   • Add sample code - unchecked
   • Everything else - defaults are fine

4. Open File > Project Structure and click Platform Settings > SDKs.

   • Click + > Add JDK...

     • It should pre-select the IntelliJ IDEA install dir. Expand it and select the jbr directory.
     • Click OK.

   • Click + > Add IntelliJ Platform Plugin SDK...

     • It should again pre-select the IntelliJ IDEA Community Edition install dir.
     • Click OK.
     • In the Select Internal Java Platform dialog, it should show the JDK selected in the Add JDK step above.
     • Click OK.

   • Click Project Settings > Project.

     • Choose the IntelliJ Platform Plugin SDK created in the Add IntelliJ Platform Plugin SDK step above as the project SDK.
     • Click OK.

5. Once indexing completes, click Run > Edit Configurations...

   • Click + > Remote JVM Debug.

     • Specify a name of ic2_remote
     • Copy the contents of Command line arguments for remote JVM.
     • Click OK.

6. Start the other JetBrains IDE and open your IC2 project where the code coverage issue occurs.

7. Click Help > Edit Custom VM Options...

   • Paste the Command line arguments for remote JVM line copied above to the end of the resulting file, e.g.:
     -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
   • Save that file.
   • Restart that IDE.

8. Return to IntelliJ IDEA and click Run > Debug 'ic2_remote'. It should open the Debug tool window and say Connected to the target VM ....

9. Click Navigate > Class and enter CoverageDataManagerImpl. It will likely prompt you to decompile it. Accept that dialog and a decompiled version of CoverageDataManagerImpl.java should be shown.
10. Find the chooseSuitesBundle() method and set a breakpoint there by clicking in the gutter to the left of the first line of that method. You should see a red ball with a checkmark on it in the gutter.
11. Right-click on the breakpoint icon and enter suite == null in the Condition field, then click Done.

12. Return to the IDE with your open IC2 project and run Apex unit tests with coverage.

    • When the test run completes and coverage is shown, the breakpoint should be hit with the debugger suspended on the first line of CoverageDataManagerImpl.chooseSuitesBundle(). If that doesn’t happen, the coverage view is being closed in some other manner. Please let me know if that’s the case.
    • Click the camera toolbar icon (Get Thread Dump) in the Debug tool window to capture a full thread dump of the IDE process.
    • Click the Copy to clipboard toolbar icon in the Dump tab and attach the resulting thread dump here or email it to me. That should tell me why coverage is being closed immediately after being displayed.

If you decide to help with this, please post a comment here so that others know that someone is already doing so. That should hopefully help mitigate the risk of multiple people spending time doing the same thing. And of course if you have any questions about the steps above, don’t hesitate to ask. Thanks in advance!

[Roman Hentschke]

I’ll take the test :)

So, here’s what I did - basically I followed your guide.

• IntelliJ Idea Ultimate 2022.3.2 already installed with IC2 2.2.5.6
• Installed IntelliJ Community Edition 2022.3.2 and also IC2 2.2.5.6
• In the community edition I created the project as you’ve described
• I started ic2_remote and set the break point including condition
• Opened a random SF project in IntelliJ Idea Ultimate
• Ran a random unit test with code coverage

‌

Here’s what happened:

• Apex Unit test ran successfully.
• Code Coverage was again visible for a sec and disappered
• Break Point did NOT hit
• I closed the apex unit test class
• Break Point did still NOT hit
• I closed the SF project and IntelliJ Ultimate completely
• Suddently: the breakpoint hit.

‌

Thread Dump is attached as log file.

‌

I am unsure, if this is what you wanted to achieve. Let me know, if we want to schedule a call. More than happy to help.

‌

[Scott Wells]

Thanks, Roman. Unfortunately the breakpoint was hit because the coverage view was closed as part of application shutdown. Hmmmm….so it appears that there’s some other path leading to the coverage view closing/disappearing. Let me see if I can track that down and I’ll provide a few other breakpoints that you should add to try to corner this.

And thank you for jumping through such strange hoops to help out here!!!

[Scott Wells]

Okay. Let’s try a different breakpoint. Please add one in CoverageViewManager.closeView(). It does not need to be a conditional breakpoint. Just add a breakpoint on the first line of that method, the reproduce the coverage view open/disappear behavior. Hopefully it’ll hit that breakpoint, and I’ll want to see stack backtrace from that point. Thanks!

[Roman Hentschke]

When I set a breakpoint in CoverageViewManager.closeView() it immediately kicked in, as soon as I click “Run unit test with code coverage”.

Log is attached.

[Scott Wells]

Thanks, Roman. Does that breakpoint get hit again once unit test execution completes? What I need to see is the call stack that results in the coverage view being closed immediately after it has been opened at the end of a “Run with coverage” test execution.

[Roman Hentschke]

unfortunately not :-(

I’ve attached a GIF showing the complete thing in action.

[Roman Hentschke]

I accidentally attached the GIF even twice

[Scott Wells]

Ah, that’s very helpful! The coverage view isn’t actually closed/removed; it’s just hidden/docked. The breakpoints I’ve provided so far assume that it’s actually removed altogether. Let me see if I can find a new breakpoint to set that will show me who/what is doing that.

[Roman Hentschke]

sure. Meanwhile a side note:

I today talked with another developer of my company. She’s using IntelliJ Idea and IC2 same version, than I do.
She is on Windows 11, all updates installed

I use MacOS 13.1 (22C65) with an Apple M1 Max

I also use a “special JDK”:

\$ java --version
openjdk 17.0.3 2022-04-19 LTS
OpenJDK Runtime Environment Zulu17.34+19-CA (build 17.0.3+7-LTS)
OpenJDK 64-Bit Server VM Zulu17.34+19-CA (build 17.0.3+7-LTS, mixed mode, sharing)

‌

Maybe this is somehow connected?

[Scott Wells]

I think it’s worth trying to eliminate variables, sure. I don’t see this behavior under Windows, Mac Mini M1, Mac Mini x64, or Ubuntu Linux, all running the bundled JetBrains JREs. It might be worth switching to the bundled JRE to see if the behavior is still present. It might also be worth disabling any other plugins aside from IC2 and the bare minimum bundled JetBrains plugins to see if it’s still there. That could help to pinpoint something that otherwise would be very difficult to find via this form of remote “debugging” of the issue.

[Roman Hentschke]

fair point.
I installed a fresh version of IntelliJ IDEA Ultimate including IC2. The Boot Runtime is not changed. Just the “standard” plugins selected… same behaviour :-( No code coverage overlay

‌

If you want to, we can schedule a screen share meeting, tomorrow or on Sunday and take a look together.

‌

[Scott Wells]

Out of curiosity, how is this configured in your IDE where this happens?

‌

[Roman Hentschke]

Same here

‌

[Scott Wells]

Okay. Worth seeing if there was a SUPER low-hanging fruit solution there, but I didn’t expect that to be the case.

I have a new breakpoint for you if/when you have a free minute. Please set a breakpoint in CoverageViewManager.activateToolWindow() and reproduce the behavior. I want to know if that breakpoint is hit more than once, and for each time it’s hit, I’d like to get the stack backtrace. One should come directly from IC2. I’m curious if the IDE is also doing it, though, which I believe might result in a toggle behavior just like what you’re seeing.

[Roman Hentschke]

After uploading the first log, I decided to create zip file and uploaded that one instead.

‌

Also another GIF is attached

[Scott Wells]

Thank you again. So if I understand correctly, activateToolWindow is actually being called three times? That’s what I’m seeing in the provided thread dumps, and I’m pretty sure that I’m seeing the same thing in the animated gif. Can you confirm that to be the case?

[Roman Hentschke]

yes… While watching the GIF again, Ive recognized that I accidentally left the other breakpoint in place. Sorry. But yes, I can confirm.

[Scott Wells]

Okay, Roman, I think I’m onto something. Let’s get information from one more breakpoint if you don’t mind. Go ahead and disable all other breakpoints and add one in BaseCoverageAnnotator.renewCoverageData. Reproduce the behavior and get stack backtraces from each hit for me to review. I’m hoping to see it hit more than once, and I’d specifically like to see why. Thanks again for all the help! I feel like we’re getting very, very close…

[Scott Wells]

Roman, one thing about the stack backtraces you’ll see there. They’re likely going to have an async component because of how they get invoked. The backtrace in the thread dump will just be:

"AWT-EventQueue-0@2518" prio=6 tid=0x26 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
      at com.illuminatedcloud.intellij.coverage.ApexCoverageAnnotator.createRenewRequest(ApexCoverageAnnotator.java:57)
      at com.intellij.coverage.BaseCoverageAnnotator.renewCoverageData(BaseCoverageAnnotator.java:38)
      at com.intellij.coverage.CoverageDataManagerImpl.renewCoverageData(CoverageDataManagerImpl.java:459)
      at com.intellij.coverage.CoverageDataManagerImpl.updateCoverageData(CoverageDataManagerImpl.java:336)
      at com.intellij.coverage.CoverageDataManagerImpl.chooseSuitesBundle(CoverageDataManagerImpl.java:307)
      at com.intellij.coverage.CoverageDataManagerImpl.lambda$coverageGathered$0(CoverageDataManagerImpl.java:396)
      at com.intellij.coverage.CoverageDataManagerImpl$$Lambda$6789/0x0000000802bba830.run(Unknown Source:..-1)
      .
      at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:838)
      at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:480)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
      at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
      at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
      at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
      at java.awt.EventDispatchThread.run(EventDispatchThread.java:92)

but in the debugger you’ll see more, e.g.:

‌

It would be very useful if you could get screenshots of the full stack trace from the Threads & Variables view so I can see across those async boundaries as well.

[Roman Hentschke]

Sure thing. (I want to have my favourite feature back - so if I can help with that: awesome)

‌

Attached is a zip file containing all the dumps, screenshots and another GIF. Hit number 2 needed three screenshots. I named them accordingly.

[Scott Wells]

Okay, that may well have contained the answer. Before I go into detail about what it showed me, let's see if it pans out in practice.

Please install this build that includes a prospective fix for this issue by downloading the archive (don't extract it) and using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu). Restart the IDE and try to reproduce the issue. No remote debugger attached or anything...just see if it still happens and let me know either way.

[Roman Hentschke]

noooo still does not work.

‌

• First test

  • My regular IntellJ Ultimate with your newest Plugin downloaded and manually installed → still not working

• Second test

  • Downloaded IntelliJ Ultimate again, installed it (with just the standard plugins), installed your plugin manually → still not working

‌

[Roman Hentschke]

I am out for today. keep me posted. I’ll continue testing tomorrow, if needed.

[Scott Wells]

It's okay. I still think we're almost there. This is a different approach to the same problem. Let's see if it makes a difference. Same install/test instructions, but if it doesn't resolve the issue, please get new thread dumps for the last breakpoint and provide your idea.log as well.

[Scott Wells]

New build. The good news is that I was able to reproduce the behavior where it calls renewCoverageData repeatedly exactly as seen in your thread dumps. The bad news is that doing so does not reproduce the tool window being hidden. So that does in fact look like a red herring unfortunately.

This build does include the adjustments for that just in case they're part of the overall issue, but it also registers an event listener that logs the caller stack trace when an tool window is hidden. As a result, it's going to yield noisy logs, but I'd rather err on the side of more information than less to get this cornered.

Install this one and reproduce the behavior, then immediately grab your idea.log and send it to me. Please don't exit the IDE process or tinker with any other tool windows as it will produce more of this diagnostic logging that's unrelated to the core issue here.

Hopefully(!!!) that will shine a bright light on why/how the Coverage tool window is being hidden, but I've already said that a few times so...we'll see.

And I know that you won't likely be providing that info until tomorrow at earliest. That's fine. Just setting this up so it's ready for you.

[Roman Hentschke]

Good morning!

So, I’ve installed the newest build, ran a single unit test with coverage and just uploaded the log.file.

‌

It still does not work.

[Scott Wells]

Thanks. Yeah, I didn’t expect this build to fix the issue since, after reproducing the repeated renewCoverageData calls locally, I still didn’t see the behavior myself. I was hoping the new logging would show me new insights around the tool window closing/docking, but it doesn’t. And that…is strange.

Okay, taking a step back, I really need to try to figure out what’s different between your environment where this happens consistently and mine where it never does. I know you’ve tried brand new installs, but they’re likely using the same user-level config if they’re the same IDE. Have you tried installing a completely different supported JetBrains IDE that’s never been installed on your machine to see if it would happen? For example, throw on PyCharm Community Edition with IC2 and see you see the same thing. That should avoid it picking up something in your IDE config that might be present in each test run so far. If it does reproduce in such a situation, it must be something about the host environment and not the IDE itself. That should at least allow us to focus on those aspects a bit.

I’m also going to check with some folks at JetBrains about how a tool window could close/dock without the corresponding events being fired because that’s what I’m seeing (or rather, not seeing) based on the latest provided log.

[Roman Hentschke]

I’ve just tested it with WebStorm (which was already installed) and PyCharm (which I just installed). Both IC2 installed from marketplace. Does not work.

Maybe I should buy a new computer? :-P

[Scott Wells]

Hah! No, but evidently I need to pick up a machine just like yours so I can debug this locally! That’s good, though, because it likely helps to rule out a whole host of potential contributors. If it reproduces on your machine with a 100% fresh install and just the IC2 plugin installed, it’s almost certainly due to a host environment difference and not some configuration change you made in your IDE, e.g., setting the Coverage tool window view mode to “Docked unpinned” (which someone at JetBrains suggested I have you check, by the way):

‌

Ugh…I was hoping we were almost there yesterday afternoon. Let me keep chewing on it. This may well go from being a solution to some kind of hack/workaround where I add logic to detect that the tool window has been hidden and re-open it. It would be a bit wonky for those experiencing this issue, but at least the end state would be what you want/expect which is that the coverage view is displayed upon run-with-coverage completion.

[Roman Hentschke]

Ayayay… crazy, mh?

But just to be clear:

• The coverage view window (this little window on the right side, which shows all classes and their coverage) is opening well - independently of being docked or in window mode, or whatever
• What I am missing is the code coverage view inside of an open APEX class on the left side next to the line numbers (this green or yellow vertical line)

(i got a little confused from your last post where you mentioned the “window” itself - this windows works fine, the whole time)

‌

[Scott Wells]

Okay, it’s a good clarification to ensure that if time has already been wasted due to a misunderstanding (hopefully not too much either way), we minimize how much additional time is wasted.

What I’ve (thought that I’ve) observed in your provided animated gif is:

1. You execute Run with Coverage for some set of Apex unit tests.
2. Once the test run completes, the Coverage tool window is opened showing a list of Apex classes and triggers with their coverage metrics…briefly.
3. A short time after being opened, the Coverage tool window is automatically hidden, though it doesn’t seem to be closed as you can still see its icon on the right-hand dock.

Based on what you’re saying, though, it sounds like step 3 above isn’t happening and the tool window properly stays open, but the actual coverage gutter annotations aren’t visible in the source editor tabs.

Can you please clarify which is a correct assessment of what you’re seeing? And if I’ve been barking up the wrong tree here, I sincerely apologize!

[Roman Hentschke]

Okay, potentially there is a little confusion:

1. I execute “Run with Coverage” for some set of Apex unit tests
2. Once the test run completes, the Coverage tool window is opened showing a list of Apex classes and triggers with their coverage metrics…briefly. No, this window opens perfectly fine and stays open as long as I want
3. A short time after being opened, the Coverage tool window is automatically hidden, though it doesn't seem to be closed as you can still see its icon on the right-hand dock Nope, this window works perfectly well.

Take a look to this screenshot, where I tried to explain my problem visually

‌

And this is what I was “complaining about” in my original issue: https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/2322/missing-code-coverage-annotation-in-apex

So, hopefully confusion is now perfect

‌

[Scott Wells]

Ah, okay. That’s a little different from what some others were seeing (I think? Now I’m not sure), but it definitely changes the diagnostic approach. No biggie, though, because even what we’ve done so far has identified some other behavior that needed to be addressed. Let me chew on how to perform some differential diagnosis on the missing gutter annotations and I’ll get back to you. I really apologize for burning your time on the wrong thing, though!

[Roman Hentschke]

No worries Scott, always happy to help on making my favourite tool better!

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.