[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) [?:?]

[cichengzi]

I'd like to know why the task result query process is interrupted in my scenario, and whether I can avoid this by modifying the source code?

[imbajin]

For HugeGraph 1.5.0, there is no built-in API to paginate the result payload of a single task. The task API supports paging when listing task metadata, but GET /tasks/{id} still loads and returns the task result as one complete value.

In your case, the result is produced by a complex Gremlin algorithm and finally becomes something like Map<String, String>. The existing vertex/edge page or shard-scan APIs cannot directly paginate that final computed map, because those APIs are storage-level cursors, while your result is an algorithm-level result set.

I don't recommend disabling task.result_size_limit or increasing the task DB executor threads as the main solution:

• Disabling the size check only removes one guard. The server still needs to save, load, decompress, serialize, and return a huge single payload through /tasks/{id}.
• A 2GB+ single task result can still block TaskStore, consume a large amount of memory, and break frontend rendering.
• The error Can't operate a tx in other threads is expected if the task transaction is used from different DB worker threads. The task transaction is thread-bound, so increasing task DB threads is not a safe workaround.

If you want to modify the source code yourself, the simplest practical direction is not to add pagination over the existing task result string. Instead, add a small chunked-output helper for Gremlin jobs, then make the task return only a small manifest.

A minimal design could be:

Gremlin algorithm
  -> compute partial entries
  -> write result chunks incrementally
  -> update task progress
  -> return a small manifest from the task result

For example, add methods to GremlinJob.GremlinJobProxy such as:

gremlinJob.writeResultChunk(String name, String content)
gremlinJob.appendResultLine(String name, String line)
gremlinJob.resultManifest()

Then the Gremlin script can write output while it is computing, instead of returning one huge Map<String, String>:

def chunk = 0
def count = 0

def buffer = new StringBuilder()

resultMap.each { key, value ->
    buffer.append(toJsonLine(key, value)).append('\n')
    count++

    if (count % 10000 == 0) {
        gremlinJob.writeResultChunk("chunk-${chunk}.jsonl", buffer.toString())
        buffer.setLength(0)
        chunk++
        gremlinJob.updateProgress(...)
    }
}

if (buffer.length() > 0) {
    gremlinJob.writeResultChunk("chunk-${chunk}.jsonl", buffer.toString())
}

return gremlinJob.resultManifest()

The final task result should be small, for example:

{
  "type": "chunked-result",
  "format": "jsonl",
  "chunk_count": 245,
  "total_count": 12345678,
  "result_uri": "/path/or/url/to/result/manifest.json"
}

This keeps /tasks/{id} lightweight and makes repeated result reads possible by reading chunk files or a dedicated result-chunk API.

For a quick single-node RocksDB deployment, writing chunks to a configured local directory is probably the smallest change. For production or distributed deployment, the same idea should use object storage, HDFS, or a dedicated result-chunk table/API, with cleanup and path/security checks.

So the recommended source-level change is:

1. Keep task result small.
2. Add a Gremlin-accessible chunk writer.
3. Store large output outside the task result.
4. Return only manifest/progress from the task.

This is much safer than making /tasks/{id} return a 2GB+ payload or trying to paginate a giant string after it has already been materialized.

[cichengzi]

Thank you so much for your help. Let me try the method you suggested.

[cichengzi]

Thank you for your reply. I have modified the source code according to your suggestion and successfully supported the method you mentioned. I added some helper functions and two interfaces, and successfully completed the block query of query results.