imbajin commented on code in PR #3060:
URL: https://github.com/apache/hugegraph/pull/3060#discussion_r3446639600
##########
hugegraph-server/hugegraph-test/src/main/java/org/apache/hugegraph/core/TaskCoreTest.java:
##########
@@ -115,6 +115,88 @@ public void testTask() throws TimeoutException {
});
}
+ @Test
+ public void testTaskWithoutResult() throws TimeoutException {
+ HugeGraph graph = graph();
+ TaskScheduler scheduler = graph.taskScheduler();
+
+ Id id = IdGenerator.of(88889);
+ HugeTask<?> task = new HugeTask<>(id, null, new SleepCallable<>());
+ task.type("test");
+ task.name("metadata-task-in-memory");
+ scheduler.schedule(task);
+
+ try {
+ Whitebox.setInternalState(task, "result", "\"in-memory-result\"");
+
+ HugeTask<?> taskWithoutResult = scheduler.task(id, false);
+ Assert.assertEquals("metadata-task-in-memory",
+ taskWithoutResult.name());
+ Assert.assertNull(taskWithoutResult.result());
+
+ Iterator<HugeTask<Object>> iter =
scheduler.tasks(ImmutableList.of(id),
+ false);
+ Assert.assertTrue(iter.hasNext());
+ taskWithoutResult = iter.next();
+ Assert.assertEquals("metadata-task-in-memory",
+ taskWithoutResult.name());
+ Assert.assertNull(taskWithoutResult.result());
+ Assert.assertFalse(iter.hasNext());
+ } finally {
+ Whitebox.setInternalState(task, "result", null);
+ }
+
+ scheduler.waitUntilTaskCompleted(id, 10);
+ scheduler.delete(id, false);
+
+ id = IdGenerator.of(88890);
+ task = new HugeTask<>(id, null, new MetadataResultCallable());
+ task.type("test");
+ task.name("metadata-task");
+ scheduler.schedule(task);
+
+ scheduler.waitUntilTaskCompleted(id, 10);
+
+ HugeTask<?> taskWithResult = scheduler.task(id, true);
+ Assert.assertEquals("\"metadata-result\"", taskWithResult.result());
+
Review Comment:
This currently proves the `withResult` switch for a small result, but it
does not reproduce the original failure mode: loading/decompressing a large
historical task result. Please add a regression case with a genuinely
large/compressed result and assert that metadata-only reads (`task(id, false)`,
`tasks(..., false)`, and ideally restore/scheduler metadata paths) do not touch
`task_result`.
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/task/DistributedTaskScheduler.java:
##########
@@ -308,8 +308,9 @@ protected <V> HugeTask<V> deleteFromDB(Id id) {
if (vertex == null) {
return null;
}
- HugeTask<V> result = HugeTask.fromVertex(vertex);
- this.tx().removeVertex(vertex);
+ HugeTask<V> result = HugeTask.fromVertex(vertex, false);
+ this.deleteTaskResultFromTx(id);
Review Comment:
Please make the cleanup expectation explicit here. This path now deletes
`~taskresult` before deleting `~task`, but
`TaskTransaction`/`TaskAndResultTransaction` run with auto-commit and
`removeTaskVertex()` commits in `afterWrite()`. If the second delete fails
after this call succeeds, we can leave a live task whose result has already
been removed. Could you either make the two removals failure-safe/atomic, or
add a targeted test/explanation showing why this intermediate state is
acceptable/recoverable?
##########
hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/api/job/TaskAPI.java:
##########
@@ -136,12 +137,17 @@ public Map<String, Object> get(@Context GraphManager
manager,
@Parameter(description = "The graph name")
@PathParam("graph") String graph,
@Parameter(description = "The task id")
- @PathParam("id") long id) {
+ @PathParam("id") long id,
+ @Parameter(description = "Whether to load
task result")
+ @DefaultValue("true")
Review Comment:
Since this introduces a new public query parameter, please update the PR
checklist/docs status accordingly, or briefly explain why the generated OpenAPI
annotation is sufficient and no user-facing docs are needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
