[Bug]: The "complete plan number" is 0 rather than the completed task number after major compaction completed

[binbinlv]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- Milvus version:  xiaocai2333-debug_datacoord_access_timeout-c8ded3d-20241227
- Deployment mode(standalone or cluster): cluster
- MQ type(rocksmq, pulsar or kafka):   pulsar 
- SDK version(e.g. pymilvus v2.0.0rc2): 2.4.13rc5
- OS(Ubuntu or CentOS): 
- CPU/Memory: 
- GPU: 
- Others:

Current Behavior

The "complete plan number" is 0 not the completed task number after major compaction completed

CompactionState
 - compaction id: 454895677326769807
 - State: Executing
 - executing plan number: 1
 - timeout plan number: 0
 - complete plan number: 0

waiting for compaction completed
major compaction is successfully in 179.932771 s

CompactionState
 - compaction id: 454895677326769807
 - State: Completed
 - executing plan number: 0
 - timeout plan number: 0
 - complete plan number: 0

after major, segments number is 10

Expected Behavior

The "complete plan number" is the completed task number after major compaction completed

Steps To Reproduce

1. create a collection with 10m data inserted (set is_cluster_key=True to an int64 field)
2. trigger major compaction to this collection

Milvus Log

granfana:
https://grafana-4am.zilliz.cc/d/uLf5cJ3Ga/milvus2-0?orgId=1&from=now-1h&to=now&var-datasource=prometheus&var-cluster=&var-namespace=qa-milvus&var-instance=major-24-ndoap&var-collection=All&var-app_name=milvus

log:
https://grafana-4am.zilliz.cc/explore?orgId=1&panes=%7B%22ITw%22:%7B%22datasource%22:%22vhI6Vw67k%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Bcluster%3D%5C%224am%5C%22,namespace%3D%5C%22qa-milvus%5C%22,pod%3D~%5C%22major-24-ndoap.%2A%5C%22%7D%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22vhI6Vw67k%22%7D%7D%5D,%22range%22:%7B%22from%22:%22now-1h%22,%22to%22:%22now%22%7D%7D%7D&schemaVersion=1

Anything else?

collection name: major_compaction_collection_enable_scalar_clustering_key_1kw

[binbinlv]

/assign @xiaocai2333

[xiaocai2333]

After the compaction task is completed, if the clean task goroutine has completed the relevant operations, it will set the tasks state to cleaned. Tasks in the cleaned state will not be returned to the SDK. Therefore, querying task-related information after compaction is completed may result is not being able to retrieve the task information, as it might have already been garbage collected.

[binbinlv]

So this is as current design?