[Bug] Potential silent thread failure in Consumers.java due to unchecked Future

[QiuYucheng2003]

Bug Type (问题类型)

logic (逻辑设计问题)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

Server Version: N/A (Found in Source Code Analysis / Master Branch)

Backend: N/A

OS: N/A

Data Size: N/A

Expected & Actual behavior (期望与实际表现)

Expected Behavior:
When Consumers threads encounter a critical error (e.g., inside ContextCallable initialization or an Error that escapes the internal try-catch), the exception should be logged or propagated to the UncaughtExceptionHandler to alert the system.

Actual Behavior:
In Consumers.java, tasks are submitted using executor.submit(...) (Line 110), but the returned Future is never checked (no future.get() is called in await() or elsewhere). This causes a "swallowed exception" scenario:

1. Exceptions occurring outside the runAndDone() internal try-catch block (e.g., in ContextCallable wrapper or strictly internal JVM errors) are captured by the Future.

2. Since the Future is ignored, these exceptions remain invisible. The system believes the consumer is running, but the thread may have terminated silently.

Code / Logs：
// Consumers.java
public void start(String name) {
// ...
for (int i = 0; i < this.workers; i++) {
// Problem: 'submit' is used but the returned Future is never checked via .get()
// If an exception happens outside runAndDone's try-catch, it is swallowed.
this.runningFutures.add(
this.executor.submit(new ContextCallable<>(this::runAndDone)));
}
}

Recommendation:
Change submit() to execute() if the return value is not needed, which allows the JVM's UncaughtExceptionHandler to catch unhandled exceptions. Or ensure future.get() is checked during the lifecycle management.

Vertex/Edge example (问题点 / 边数据举例)

N/A

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

N/A

[dosubot]

Hi @QiuYucheng2003! I'm Dosu and I’m helping the incubator-hugegraph team.

Your analysis is correct: in Consumers.java, using executor.submit() without ever calling Future.get() can cause exceptions thrown outside the main runAndDone() logic (such as in ContextCallable initialization or JVM errors) to be silently swallowed, resulting in undetected thread failures. The code currently logs and stores exceptions only if they occur inside runAndDone(), but any exception outside that scope is captured by the Future and never surfaced, since await() does not check the Futures at all. This means the system may believe all consumer threads are healthy when some have actually failed silently cite 1.

Your recommendation is spot on: switching to executor.execute() (if you don't need the Future) lets the JVM's UncaughtExceptionHandler catch and log unhandled exceptions, making failures visible. Alternatively, explicitly calling Future.get() (as shown in ExceptionUtil.futureGet and BaseUnitTest.runWithThreads) ensures exceptions are not missed cite 2 cite 3.

No similar issues or fixes for this bug have been discussed or merged in the HugeGraph repository so far. Your report highlights a real risk and a clear improvement for thread reliability and observability.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[bitflicker64]

@dosu submit() itself isn’t the core problem here: runAndDone() already catches Throwable, logs/stores the exception, and (when entered) counts down the latch.

The real issue is **before runAndDone() runs: if ContextCallable.call() throws during context init, runAndDone() is never entered → latch.countDown() never happens → await() can hang forever, and the exception stays hidden in the Future since no get() is called.

I’ll fix this by wrapping the ContextCallable execution so latch.countDown() always happens , and remove the countdown from runAndDone() to avoid double-counting.

[bitflicker64]

@dosu PR opened to fix #2939: <PR_LINK> #2941 . Root cause is ContextCallable failing before runAndDone(), skipping latch.countDown() and potentially hanging await(). This PR wraps execution in safeRun() so latch is always decremented.