[Improvement] [API] Improve the task instance large-field optimization to align with the WorkflowInstance approach

Author: njnu-seafishCreated Aug 27, 2026Updated Sep 27, 2026
LabelsimprovementbackendStale

Search before asking

  • I had searched in the issues and found no similar feature requirement.

Description

Background

PR #18442 optimized TaskInstanceMapper by introducing lightweight projections (listSql/listSqlV2) that omit the heavy text columns task_params and var_pool from list queries. The intent is correct, but the initial implementation is too minimal compared with the later workflow-instance optimization (#18444):

1.Silent API contract change. The list APIs still serialize the full TaskInstance entity, so taskParams/varPool now silently become null in responses — with no incompatible.md entry and no VO-level documentation, consumers cannot tell this is intentional.

2.Projection applied to non-list queries. Methods whose names do not imply "list" were also switched to the light projection: queryByInstanceIdAndCode is effectively a single-row/detail lookup, yet now omits task_params; findLastTaskInstances/findLastTaskInstance are consumed by the master dependency calculation (DependentExecute → queryLastTaskInstanceListIntervalInWorkflowInstance), an internal execution path that may later need the full row.

3.No dedicated DTO/VO. Results are still mapped into the full TaskInstance entity, so the "list contract" cannot be expressed at the type level, and columns that the list UI never needs (e.g. execute_path, log_path, app_link) still leak through.

4.No shape-level tests. TaskInstanceMapperTest only asserts non-null / row counts; nothing verifies which fields a list query must not return.

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct