CloseAllHandlerTest fails

[jukzi]

          New test seems to be unstable failed (at least):

• https://download.eclipse.org/eclipse/downloads/drops4/I20241022-1800/testresults/html/org.eclipse.ui.tests_ep434I-unit-cen64-gtk3-java23_linux.gtk.x86_64_23.html
• https://download.eclipse.org/eclipse/downloads/drops4/I20241022-1800/testresults/html/org.eclipse.ui.tests_ep434I-unit-cen64-gtk3-java17_linux.gtk.x86_64_17.html

Originally posted by @akurtakov in #2360 (comment)

java.lang.IllegalStateException: Application does not have an active window
at org.eclipse.e4.ui.internal.workbench.ApplicationPartServiceImpl.getActiveWindowService(ApplicationPartServiceImpl.java:53)
at org.eclipse.e4.ui.internal.workbench.ApplicationPartServiceImpl.createPart(ApplicationPartServiceImpl.java:167)
at org.eclipse.ui.tests.e4.CloseAllHandlerTest.createAndOpenE4Part(CloseAllHandlerTest.java:200)
at org.eclipse.ui.tests.e4.CloseAllHandlerTest.testCloseMixedEditorTypes(CloseAllHandlerTest.java:117)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
            

[jukzi]

@feilimb As contributor please fix the contributed failing test.
daily builds can be found in https://download.eclipse.org/eclipse/downloads/index.html

[feilimb]

@feilimb As contributor please fix the contributed failing test. daily builds can be found in https://download.eclipse.org/eclipse/downloads/index.html

@jukzi I will try to look into it. The failure seems to only occur on one of the platforms (and sometimes on 2 platforms), a Java 23 Linux build: ep434I-unit-linux-x8664-java23_linux.gtk.x86_6423.

Do you have any experience / advice on how to approach looking into this, as I do not have a Linux system I could try to reproduce the failure on currently. Is there a history for some specific scenarios where test passes on most platforms, but fails on a single platform?

[jukzi]

Typically it helps to set a breakpoint at the location that changes the state, another breakpoint at the condition, run the test in debug mode and hopefully see that things happens in different threads or actions that run in arbitrary order. And sometimes it's much harder. Once the race condition identified it's needed to add some synchronization. waiting for another thread, or makeing sure something has has already happend before scheduling something. Good luck!

[akurtakov]

@feilimb It fails on Linux when using Java 21 and/or 23 while Windows and Mac runs on Java 17 only. Maybe the issue is reproducible locally on Win/Mac if running Java 21/23? It's worth trying.

[feilimb]

Thanks @jukzi and @akurtakov , I will try the Windows with Java 21/23 idea initially and see if I can reproduce.

[feilimb]

@feilimb It fails on Linux when using Java 21 and/or 23 while Windows and Mac runs on Java 17 only. Maybe the issue is reproducible locally on Win/Mac if running Java 21/23? It's worth trying.

@akurtakov
Unfortunately trying with both Java 21 and Java 23 did not reproduce a test failure for me, when running the test dozens of times on Windows 10.

I am considering simply switching the order of the first and second scenarios tested within the test, which might effectively resolve the race condition which must be occurring on the Linux build / test workflow.

Am I correct that I should create a new Pull Request for the test update? In order to see if the idea works, can one see test results within the PR workflow (for all Platforms) ?

[jukzi]

you can try with a new PR. Problem is that even if PR runs fine it may fail during CI builds due to other timing behaviour.

[iloveeclipse]

Haven't looked into what the test does, but the reported error most likely means that one should make sure in setup that window is active and has focus. If the test opens closes shells etc it might need to process ui events to get main window a chance to become active again.

[feilimb]

you can try with a new PR. Problem is that even if PR runs fine it may fail during CI builds due to other timing behaviour.

It feels like Catch-22, as I cannot reproduce the failure, I can create a PR with potential workaround, but cannot verify that PR will resolve, even if the workflows look good within it.

@iloveeclipse regards your comment, I don't suppose you know of any other pre-existing tests which 'block/wait' until org.eclipse.e4.ui.internal.workbench.ApplicationPartServiceImpl.getActiveWindowService() is 'ready'.

(ie. for the main Application instance which may be retrieved via:

  BundleContext bundleContext = FrameworkUtil.getBundle(IWorkbench.class).getBundleContext();
  ServiceReference<IWorkbench> reference = bundleContext.getServiceReference(IWorkbench.class);
  bundleContext.getService(reference).getApplication();

)

[iloveeclipse]

As said, I didn't checked code, I just saw enough broken tests because of main shell was not active (yet/again) after opening / closing new shells.

[feilimb]

Possible fix via PR submitted now:
#2463

[feilimb]

This Issue can be closed now as the test is consistently passing since my update about 5 days ago :)