Custom start is getting stuck while trying to access messages.log

[aparnamichael]

While running custom start tests, inconsistently getting stuck at the same step.

org.opentest4j.AssertionFailedError: testStartWithConfigInRunModeUsingMenu:validateLibertyServerStopped: Exit. Timed out waiting for message CWWKE0036I in log:D:\a\liberty-tools-intellij\liberty-tools-intellij\liberty-tools-intellij\src\test\resources\projects\maven\singleModMavenMP\target\liberty\wlp\usr\servers\defaultServer\logs\messages.log

***Note: This error is occurring with other tests as well, running in Windows. Refer to https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/10592982820/job/29362112582?pr=932

[aparnamichael]

The same timeout issue is present in Linux builds as well, the server is not starting within the 90 seconds timeout. When we increase the timeout all the tests are passing.

[vaisakhkannan]

As part of the investigation, we decided to collect the terminal logs for the running projects. After making some changes to the code in the build.yaml file and modifying some changes in some test classes to use Robot UI for terminal log collection, we were able to retrieve the terminal logs.

Eg: https://github.com/vaisakhkannan/liberty-tools-intellij/actions/runs/11167740653

Branch that has the changes - https://github.com/vaisakhkannan/liberty-tools-intellij/tree/windows_test_new

I have shared the changes with Anusree, and she is implementing them in her fork and analyzing the issue.

[anusreelakshmi934]

We weren't able to gather much additional information from the terminal log captures; the output was similar to what we typically see in the GHA builds. Despite increasing the timeout to 10 minutes, a few tests are still failing—about 1 in 10—mirroring the failure rate seen without any fixes.

In the current scenario, without any fixes 10 out of 80 builds faces this issue.

Here are the different methods we've tried to stop the server after each test:

• Closing the terminal after each test.
• Killing the port after each test.
• Running mvn/gradle clean after each test.
• Running mvn/gradle clean after each test and closing the terminal tab.
• Running mvn/gradle liberty:stop and closing all terminal tabs after each test.

These methods don't appear to significantly impact the test success rate.

[anusreelakshmi934]

After running mvn liberty:stop and gradle libertyStop along with closing the terminal after each test, we observed the following results: GitHub Actions Run.

From the videos of the failed tests, we see that the Liberty server delay isn't limited to just startup—there is also a significant delay when executing gradle libertyStop, which doesn’t fully complete in time, causing subsequent tests to fail.

[anusreelakshmi934]

We ran mvn liberty:stop/gradle libertyStop after each test by opening a new terminal, then closed all open terminal tabs. Next, we opened a new terminal to run mvn/gradle clean and again closed all open terminal tabs. Following this approach, we are now getting successful (green) builds.

[turkeylurkey]

Same as #428. Should close that one.