Once a test suite fails at a certain point, it takes a long time to terminate from the failure point. This issue occurs both locally and in the CI/CD environment. In such cases, the CI/CD pipeline shows the execution as 100% complete, but the test report is not generated, making it difficult to analyze the root cause. How can we avoid or reduce this long delay after a test failure and ensure that reports are generated correctly?
How long is it? 30 seconds? 30 minutes? or 30 hours?
The delay varies from case to case, but in most instances it takes more than 5 minutes to exit after a test failure.
Please provide a execution log with full content (no trim) that shows a long wait time after test failure.
There can be many reasons for this delay which you are observing, I have particularly 3 different questions
-
Are you running the test in headless mode?
In headless Chrome, if the process isn’t cleanly terminated, it can keep the JVM alive well past the point where CI/CD thinks the job is “done” — and report writers that depend on a clean shutdown hook may never actually fire, which would explain both the delay and the missing report. I am asking this because you have mentioned it is happening inside a CI/CD container, it’s worth checking whether the browser process is being force-killed on failure. -
Whether your test scenario has OS level popup interaction?
If any native OS-level popup appears during execution — a file upload/download dialog, password changing notification, a basic-auth prompt, or an SSL certificate warning — WebDriver has no way to interact with it, since these aren’t part of the browser DOM. In that case, the command just blocks and waits indefinitely for a response that never comes, which can look exactly like a long hang after a failure point.
Below point is very generic which we usaully check, so I assume you might have checked the time out in the setting.
3) Check the Katalon time out timing mentioned in the project.
Particularly in my test, I too have faced the almost similar issue long back, and I remember OS popup was causing the issue.
tasklog_6.log (4.1 MB)The final two reports were not generated. Please refer to the attached log file for more information.
There can be many reasons for your issues, but some of the prominent one which I can see are as below
- MSG_RP_ERROR_RESULT_QUOTA_EXEEDED → Shows that the TestOps result quota may have been exceeded. The quota problem can delay or prevent result processing and report generation.
What you can do:
a) Archive or delete obsolete execution results if permitted.
b) Increase the available result quota if required.
c) Reduce retained attachments such as screenshots, videos, and large logs if they are not needed for every test
- Prominent issue is linked with the HRM-REPORTNAVIGATOR45-MVC which is keeping the test run hanging, so can you please review
- Custom keywords and teardown hooks for:
WebUI.waitForElementPresentWebUI.waitForPageLoadWebUI.waitForElementVisible- browser alerts
- downloads/uploads
- report exports
- unbounded loops
- Add explicit, reasonable timeouts to all waits.
- Make sure every browser and driver is closed in teardown, but avoid teardown code that waits indefinitely.
In the original post, @sophia wrote:
On the other hand, in the tasklog_6.log, I could not find anything that informs me of “a test suite fails at a certain point”. To me, this log describes nothing about the problem that @sophia.n mentioned.
How did sophia know that a test suite failed?
Hmm points worth noting My Lord 
The failing test cases are also failing locally, and I need to fix them. However, the number of failures is relatively small. Could these failures be causing the execution to hang? Normally, failing test cases should not cause the entire execution to hang.
Sometime failure also cause hang, it depends on the. Some of the prominent reasons which can make the execution hang I have listed above. Please check
Whether a failure in test case causes the entire exectuion to hang or not — it depends on the way how you coded your tests. Do you want a failure in test cases to cause the entire execution to hang? — Possibly it is possible but you need to code your test so that it makes the entire execution to hang.
How to?
I have no idea because you disclosed too little information about the failure you got. If you want others to help you, you should study the failure you got for yourself, and provide the detail information of the failure (log, source code, screenshot, etc). Without the detail information of the failure to look into, it is difficult for me to think about it.
Or better use this listener, it will kill the test case which is unwantedly getting hung. Once you get the list of test cases, check manually what is causing this effect then try removing it
import static com.kms.katalon.core.checkpoint.CheckpointFactory.findCheckpoint
import static com.kms.katalon.core.testcase.TestCaseFactory.findTestCase
import static com.kms.katalon.core.testdata.TestDataFactory.findTestData
import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject
import com.kms.katalon.core.checkpoint.Checkpoint as Checkpoint
import com.kms.katalon.core.model.FailureHandling as FailureHandling
import com.kms.katalon.core.testcase.TestCase as TestCase
import com.kms.katalon.core.testdata.TestData as TestData
import com.kms.katalon.core.testobject.TestObject as TestObject
import com.kms.katalon.core.webservice.keyword.WSBuiltInKeywords as WS
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import com.kms.katalon.core.mobile.keyword.MobileBuiltInKeywords as Mobile
import internal.GlobalVariable as GlobalVariable
import com.kms.katalon.core.annotation.BeforeTestCase
import com.kms.katalon.core.annotation.BeforeTestSuite
import com.kms.katalon.core.annotation.AfterTestCase
import com.kms.katalon.core.annotation.AfterTestSuite
import com.kms.katalon.core.context.TestCaseContext
import com.kms.katalon.core.context.TestSuiteContext
import com.kms.katalon.core.util.KeywordUtil
import java.util.concurrent.Executors
import java.util.concurrent.ScheduledExecutorService
import java.util.concurrent.ScheduledFuture
import java.util.concurrent.ThreadFactory
import java.util.concurrent.TimeUnit
import java.util.List
import java.util.stream.Collectors
class HangWatch {
private static final long TEST_CASE_TIMEOUT_MIN = 6
private static volatile boolean suiteAborted = false
private static volatile ScheduledFuture<?> pending
private static final ScheduledExecutorService scheduler =
Executors.newSingleThreadScheduledExecutor({ Runnable runnable ->
Thread thread = new Thread(runnable, 'hang-watchdog')
thread.setDaemon(true)
return thread
} as ThreadFactory)
@BeforeTestSuite
def beforeSuite(TestSuiteContext ctx) {
suiteAborted = false
if (pending != null) {
pending.cancel(false)
pending = null
}
}
@BeforeTestCase
def beforeTestCase(TestCaseContext ctx) {
if (suiteAborted) {
KeywordUtil.logInfo(
"Watchdog: skipping ${ctx.testCaseId}; the suite was aborted."
)
ctx.skipThisTestCase()
return
}
String testCaseId = ctx.testCaseId
// Cancel any previous watchdog before scheduling a new one.
if (pending != null) {
pending.cancel(false)
pending = null
}
pending = scheduler.schedule({
suiteAborted = true
KeywordUtil.logInfo(
"Watchdog: ${testCaseId} exceeded " +
"${TEST_CASE_TIMEOUT_MIN} minutes. Killing the browser."
)
killBrowser()
} as Runnable, TEST_CASE_TIMEOUT_MIN, TimeUnit.MINUTES)
}
@AfterTestCase
def afterTestCase(TestCaseContext ctx) {
if (pending != null) {
pending.cancel(false)
pending = null
}
}
private static void killBrowser() {
try {
List<ProcessHandle> processes = ProcessHandle.current()
.descendants()
.collect(Collectors.toList())
processes.each { ProcessHandle processHandle ->
String command = processHandle.info()
.command()
.orElse('')
.toLowerCase()
if (command.contains('chromedriver') ||
command.contains('chrome')) {
KeywordUtil.logInfo(
"Watchdog: terminating process ${command}"
)
processHandle.destroyForcibly()
}
}
} catch (Throwable error) {
KeywordUtil.logInfo(
"Watchdog: browser termination failed: ${error.message}"
)
}
}
}
whether your problem got resolved?
We are experiencing a persistent issue where test execution hangs indefinitely or takes an excessive amount of time to terminate after a failure occurs, affecting both local environments and CI/CD runners where pipelines show 100% completion yet fail to generate or publish the final test report. This blocks effective debugging because failure logs and reports are lost or inaccessible. This behavior is typically caused by hanging teardown hooks (afterEach/afterAll cleanups), dangling database connections, unclosed servers, or open asynchronous operations like unresolved promises and active timers that prevent the test runner’s event loop from exiting. To resolve this, we should audit our cleanup blocks to ensure all connections and mocks properly close, configure the test runner to force-flush results immediately upon failure, implement strict global timeouts so processes kill themselves instead of hanging, and run the suite with open-handle detection flags locally to isolate the blocking resources.
Nice insight, welcome to the community
@sophia.n one cheap experiment before touching the tests. arvind already spotted MSG_RP_ERROR_RESULT_QUOTA_EXEEDED in your log, that comes from the report upload to testops / true platform at the end of the run. the symptom you describe, pipeline says 100% but the exit takes 5+ minutes and the last reports are missing, is exactly what i have seen when that upload is retrying or timing out after the suite has finished.
so run the same suite once with the integration disabled (project > settings > katalon platform, untick the report upload) or with the katalon cli flag that skips it. if the exit is fast and the html reports show up in the Reports folder, you know the hang is in the upload step and not in your failed test cases, and the quota is what you need to fix. if it is still slow, then it really is a test, and arvind’s watchdog listener is the next step to find which one.
also worth checking that your ci job is not killing the jvm on a hard timeout, that is the usual reason the report folder ends up half written.