Error when searching tests

[jdneo]

sample project: https://github.com/junit-team/junit5

try to expand the test node junit-jupiter-engine:

Java Model Exception: Error in Java Model (code 969): <anonymous #1> {key=Lorg/junit/jupiter/api/AssertThrowsAssertionsTests$7029;} [in execute() [in <lambda #1> [in assertThrowsWithExecutableThatThrowsInstanceOfAnonymousInnerClassAsUnexpectedException() [in AssertThrowsAssertionsTests [in AssertThrowsAssertionsTests.java [in org.junit.jupiter.api [in src/test/java [in junit-jupiter-engine]]]]]]]] does not exist
	at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:574)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:617)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:328)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:314)
	at org.eclipse.jdt.internal.core.Member.getFlags(Member.java:172)
	at org.eclipse.jdt.internal.junit.util.CoreTestSearchEngine.isAccessibleClass(CoreTestSearchEngine.java:64)
	at org.eclipse.jdt.internal.junit.launcher.JUnit5TestFinder.internalIsTest(JUnit5TestFinder.java:251)
	at org.eclipse.jdt.internal.junit.launcher.JUnit5TestFinder.findTestsInContainer(JUnit5TestFinder.java:221)
	at com.microsoft.java.test.plugin.searcher.JUnit5TestSearcher.findTestItemsInContainer(JUnit5TestSearcher.java:130)
	at com.microsoft.java.test.plugin.util.TestSearchUtils.findTestPackagesAndTypes(TestSearchUtils.java:168)
	at com.microsoft.java.test.plugin.handler.TestDelegateCommandHandler.executeCommand(TestDelegateCommandHandler.java:56)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:230)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:220)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:597)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

[rgrunber]

I think we also ran into this issue at eclipse-jdtls/eclipse.jdt.ls#2821 (comment) . We were intending to allow delegate commands to report progress, but then found a particular delegate command declared by com.microsoft.java.test.plugin whose failure would result in the progress never finishing properly.

[jdneo]

Hi @rgrunber

Does that mean that if there is any unhandled exception thrown from delegate command, the progress will hang forever?

Will it work if we kill the progress in https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/847f305bff93d621498c496aa3de8b3a75d8a186/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/WorkspaceExecuteCommandHandler.java#L235?

[rgrunber]

If a delegate command (eg. contributed from an external bundle) allocates some sub-monitor with a certain amount of work, and fails to fill the monitor (or call done()), or encounters an error and fails to fill the monitor, then yes, the client-side progress bar that reports/monitors tasks would hang IF we were to merge https://github.com/eclipse-jdtls/eclipse.jdt.ls/pull/2821/files .

That's partly why we're not merging that PR yet. It might be something to discuss further given this could introduce a lot of "progress bar spins forever" issues for delegates if they end up misbehaving. However, if you look around JDT-LS, or even the Eclipse ecosystem, you'll see it's a common practice to do :

} finally {
  monitor.done()
}

Maybe we can use that there in handleException.. It wouldn't fix the error here, but it could certainly mitigate the unwanted "progress bar spins forever" behaviour.

Update: It doesn't work but I think this is for a few reasons. The handleException callback isn't triggered. Also, I suspect calling done() on some parent monitor, would only result in sending done progress for that particular task and not any of its children. We need to get at the actual child and call done() on it. Also it doesn't seem progress monitors have a way to access their children :\ I need to investigate this more.

I think the stack trace is independent of the unfinished task. It might be an upstream (jdt.core) issue in how the API is used. I'm observing that the index search progress hangs at 75% and then the error is thrown.

[jdneo]

Let me know if I can do something on my side. :)