[Question] After I completed a query that retrieved a particularly large amount of data, my HugeGraph front end could no longer display the task list, showing "Failed to update/query TaskStore: java.lang.InterruptedException".

[cichengzi]

Problem Type (问题类型)

rest-api (结果不合预期)

Before submit

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

Environment (环境信息)

• Server Version: 1.5.0 (Apache Release Version)
• Backend: RocksDB
• OS: 4 CPUs, 32 G RAM, Ubuntu 22.0
• Data Size: 450w+ vertices, 1000w+ edges

Your Question (问题描述)

My Gremlin query retrieved a large amount of data; the original query results were stored as JSON, totaling about 1GB. Now I can no longer query the task through the task list. Furthermore, I can no longer retrieve results individually via an API like http://${IP}:${PORT}/graphs/${GRAPH_NAME}/tasks/${TASK_ID}. What should I do?

{
"exception": "class org.apache.hugegraph.HugeException",
"message": "Failed to update/query TaskStore: java.lang.InterruptedException",
"cause": "java.lang.InterruptedException"
}

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

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

[dosubot]

This issue is likely caused by the task result (~1GB JSON) exceeding the default task.result_size_limit (16MB by default), which corrupted/stuck the task in the TaskStore. Tasks in HugeGraph are stored as graph vertices internally (~task and ~taskresult labels), and when the result is too large, it can fail during save and leave things in a broken state [1].

To recover, try force-deleting the problematic task via REST API:

DELETE http://${IP}:${PORT}/graphs/${GRAPH_NAME}/tasks/${TASK_ID}?force=true

Example:

curl -X DELETE "http://${IP}:${PORT}/graphs/${GRAPH_NAME}/tasks/${TASK_ID}?force=true"

If even this API call hangs/fails due to the InterruptedException, you may need to restart the HugeGraph server first, then immediately issue the delete before the stuck task causes issues again.

To prevent this in the future, increase the task result size limit in your graph configuration file (e.g., conf/graphs/hugegraph.properties) [2]:

task.result_size_limit=1073741824

However, storing 1GB results as task output is not ideal. Consider paginating your Gremlin queries (using .range() or .limit()) instead of retrieving all results at once.

If the REST API is completely unresponsive, since tasks are stored as vertices in RocksDB, a last-resort option would be to directly clean up the backend data, though this is risky. A server restart should restore normal operation for other tasks once the stuck task is cleared.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[cichengzi]

However, in my extreme scenario, I need to support the export of data exceeding 2GB. Your configuration item here is of type int, right? Also, after adjusting it, if I view the task list in the Hugegraph front end, the total recalled data of the tasks exceeds 2GB, and I still cannot view the tasks. Furthermore, I need to query the results of the task multiple times normally, and this method is not feasible.

[dosubot]

You're right that the task result mechanism isn't suitable for your use case. While task.result_size_limit is technically a Long type, it has a hard upper limit of 1 GB enforced by a range validator [1] — so even adjusting it won't get you to 2GB+. Additionally, task results are stored and retrieved as a single complete compressed blob with no support for chunked/paged retrieval [2].

For exporting data exceeding 2GB, the async task result approach fundamentally doesn't fit. Instead, consider these alternatives:

1. hugegraph-tools dump/backup commands (recommended for bulk export):

• Designed specifically for large datasets with shard-based parallel processing [3]
• Supports configurable --split-size, --thread-num, and output to local or HDFS [4]
• Example: hugegraph-tools dump --split-size 1048576 --thread-num 4 --directory ./export/

2. Scan API with pagination (for programmatic/custom export):

• Use /graphs/{graph}/graph/vertices/scan with start, end, and page parameters [5]
• Split the keyspace into shards via /graphs/{graph}/graph/vertices/shards?split_size=...
• Iterate through shards to export incrementally without hitting memory limits

3. Gremlin pagination (for filtered queries):

• Use .range(start, end) in your Gremlin query to paginate results client-side

These approaches let you stream/paginate results rather than materializing everything into a single task result, which is the core problem with the current approach.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[cichengzi]

None of the methods you mentioned are very suitable for me.

[imbajin]

Thanks for the clarification. I think this case should not be solved by increasing task.result_size_limit.

HugeGraph already has pagination/cursor-like APIs for some data access paths, for example:

• Vertex API pagination
• Traverser shard scan APIs:
  • GET /graphspaces/{graphspace}/graphs/{graph}/traversers/vertices/shards?split_size=...
  • GET /graphspaces/{graphspace}/graphs/{graph}/traversers/vertices/scan?start=...&end=...&page=...&page_limit=...
  • similar APIs also exist for edges

For a large full-data export, the recommended direction should be based on this paged/sharded scan model:

get shards
  -> scan each shard page by page
  -> write results into chunk files
  -> task stores only metadata/progress/manifest

The task result itself should remain small. It should store metadata such as status, progress, error, and optionally an output manifest or file URI, not a 1GB/2GB+ JSON payload.

However, this does not mean every API can support the same page semantics. The existing page token works well for storage-level scans or some simple list queries, but arbitrary Gremlin/traversal results may involve traversal state, aggregation, ordering, deduplication, or path expansion. Those results cannot always be resumed by a backend scan page token.

So I think we should distinguish the cases:

Case	Suggested handling
Full vertex/edge export	Use shard + scan + page/page_limit
Simple list/query APIs	Support page/limit where the result order and cursor are well-defined
Arbitrary Gremlin large result	Do not return it through /tasks/{id} as one huge result
Reusable 2GB+ query output	Needs a streaming/chunked export job or an API-specific cursor/result-set model

In short, HugeGraph does have paged scan APIs, and they are the right foundation for bulk export. But /tasks/{id} should not be treated as a bulk result download API. Large results should be paged, chunked, or streamed, while the task only tracks the export metadata.

[cichengzi]

In Hugegraph 1.5.0, how can I implement paginated queries for the results of a task? Currently, the result of my task is a string object similar to a Map<String, String>.

[cichengzi]

I didn't see the corresponding API in the official documentation: https://hugegraph.apache.org/cn/docs/clients/restful-api/task/

[cichengzi]

I'm not simply querying edges or nodes; there's a whole complex algorithm in Gremlin, roughly 450+ lines long, and the final result is a Map<String, String> structure. How can I support pagination in this?

[cichengzi]

Or rather, is there any way for me to disable this check and prevent it from throwing an InterruptedException to interrupt my query? Currently, the query uses only one thread. Is it possible to use multiple threads? Actually, when I adjusted it to four threads, the following exception occurred:

2026-06-09 16:10:19 [main] [ERROR] o.a.h.d.HugeGraphServer - HugeRestServer start error:
org.apache.hugegraph.HugeException: Failed to update/query TaskStore: java.util.concurrent.ExecutionException: org.apache.hugegraph.backend.BackendException: Can't operate a tx in other threads
at org.apache.hugegraph.task.StandardTaskScheduler.call(StandardTaskScheduler.java:718) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.StandardTaskScheduler.queryTask(StandardTaskScheduler.java:663) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.StandardTaskScheduler.queryTask(StandardTaskScheduler.java:658) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.StandardTaskScheduler.findTask(StandardTaskScheduler.java:544) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.StandardTaskScheduler.restoreTasks(StandardTaskScheduler.java:141) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.StandardHugeGraph.serverStarted(StandardHugeGraph.java:301) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.core.GraphManager.serverStarted(GraphManager.java:484) ~[hugegraph-api-1.5.0.jar:0.71.0.0]
at org.apache.hugegraph.core.GraphManager.init(GraphManager.java:125) ~[hugegraph-api-1.5.0.jar:0.71.0.0]
at org.apache.hugegraph.server.ApplicationConfig$GraphManagerFactory$1.onEvent(ApplicationConfig.java:143) ~[hugegraph-api-1.5.0.jar:0.71.0.0]
at org.glassfish.jersey.server.internal.monitoring.CompositeApplicationEventListener.onEvent(CompositeApplicationEventListener.java:49) ~[jersey-server-3.0.3.jar:?]
at org.glassfish.jersey.server.internal.monitoring.MonitoringContainerListener.onStartup(MonitoringContainerListener.java:56) ~[jersey-server-3.0.3.jar:?]
at org.glassfish.jersey.server.ApplicationHandler.onStartup(ApplicationHandler.java:711) ~[jersey-server-3.0.3.jar:?]
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.start(GrizzlyHttpContainer.java:330) ~[jersey-container-grizzly2-http-3.0.3.jar:?]
at org.glassfish.grizzly.http.server.HttpHandlerChain.start(HttpHandlerChain.java:376) ~[grizzly-http-server-3.0.1.jar:3.0.1]
at org.glassfish.grizzly.http.server.HttpServer.setupHttpHandler(HttpServer.java:268) ~[grizzly-http-server-3.0.1.jar:3.0.1]
at org.glassfish.grizzly.http.server.HttpServer.start(HttpServer.java:245) ~[grizzly-http-server-3.0.1.jar:3.0.1]
at org.apache.hugegraph.server.RestServer.start(RestServer.java:70) ~[hugegraph-api-1.5.0.jar:0.71.0.0]
at org.apache.hugegraph.server.RestServer.start(RestServer.java:177) ~[hugegraph-api-1.5.0.jar:0.71.0.0]
at org.apache.hugegraph.dist.HugeRestServer.start(HugeRestServer.java:31) ~[hugegraph-dist-1.5.0.jar:1.5.0]
at org.apache.hugegraph.dist.HugeGraphServer.(HugeGraphServer.java:61) ~[hugegraph-dist-1.5.0.jar:1.5.0]
at org.apache.hugegraph.dist.HugeGraphServer.main(HugeGraphServer.java:127) ~[hugegraph-dist-1.5.0.jar:1.5.0]
Caused by: java.util.concurrent.ExecutionException: org.apache.hugegraph.backend.BackendException: Can't operate a tx in other threads
at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
at java.util.concurrent.FutureTask.get(FutureTask.java:191) ~[?:?]
at org.apache.hugegraph.task.StandardTaskScheduler.call(StandardTaskScheduler.java:715) ~[hugegraph-core-1.5.0.jar:1.5.0]
... 20 more
Caused by: org.apache.hugegraph.backend.BackendException: Can't operate a tx in other threads
at org.apache.hugegraph.backend.tx.AbstractTransaction.checkOwnerThread(AbstractTransaction.java:358) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.backend.tx.GraphTransaction.joinTxRecords(GraphTransaction.java:2059) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.backend.tx.GraphTransaction.joinTxVertices(GraphTransaction.java:2017) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.backend.tx.GraphTransaction.queryVertices(GraphTransaction.java:855) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.StandardTaskScheduler.lambda$queryTask$5(StandardTaskScheduler.java:683) ~[hugegraph-core-1.5.0.jar:1.5.0]
at org.apache.hugegraph.task.TaskManager$ContextCallable.call(TaskManager.java:497) ~[hugegraph-core-1.5.0.jar:1.5.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]