contrueCT commented on issue #3071: URL: https://github.com/apache/hugegraph/issues/3071#issuecomment-4853059578
Thanks for working on this. I think the general direction of splitting large task results is reasonable, but the current plan/implementation still has a few design gaps that should be addressed first. One important concern is that the chunking logic is placed in HugeTask.asArray(). This is relatively late in the task lifecycle: the result has already been fully materialized and serialized, and HugeTask.set() may already check task.result_size_limit before the data reaches asArray(). So for oversized results, the task can still fail before the chunking path is used. Another concern is that the current task-result model has already been changed to store results separately through HugeTaskResult. If chunking is only implemented in HugeTask, the actual persisted result path may still remain a single blob in HugeTaskResult. The design probably needs to be centered around the result-storage layer instead. The pagination part may also need clarification. If the server still needs to load, decompress, and parse the full result before slicing a page, then pagination mainly reduces response size, but may not fully address server-side memory/read cost. It would be good to make this limitation explicit or adjust the design toward more incremental reads. I’d suggest revising the design around HugeTaskResult, using a fixed and backward-compatible chunk storage model, clarifying how task.result_size_limit should work with chunked results, and adding tests that cover the real persisted result path and old-format compatibility. -- 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]
