`/get_backup` API succeeds with empty result for invalid `backup_name`

[sangheee]

Hi, I have a question regarding the behavior of the /get_backup API when an invalid/non-existent backup_name is provided.
When I call get_backup with a backup_name that does not exist, the API returns success, but the returned backup info is always empty.
(milvus-backup version is v0.5.9)

$ curl -XGET "http://localhost:8080/api/v1/get_backup?backup_name=nonexist" 

{
  "msg": "success",
  "data": {
    "state_code": 0,
    "progress": 0,
    "size": 0,
    "meta_size": 0
  }

This seems to be caused by the following code

milvus-backup/core/server/get_backup.go

Lines 90 to 93 in 8c6e5f8

	task, err := h.taskMgr.GetBackupTaskByName(backupName)
	if err != nil && !errors.Is(err, taskmgr.ErrTaskNotFound) {
	return nil, fmt.Errorf("server: get backup task %w", err)
	}

If the given backup_name does not exist, I expected get_backup to return an error (e.g., NotFound).
In contrast, get backup by id fails properly when the backup does not exist, so this behavior difference is a bit confusing.

Is returning success with an empty payload for a non-existent backup_name an intended behavior?
If it is intended, could you share the rationale (e.g., compatibility, client behavior expectations, etc.)?
If it is not intended, would you be OK with me submitting a PR to make /get_backup return an error when backup_name is not found?

Thanks!

[huanghaoyuanhhy]

You’re right — this behavior is not ideal, and the logic here is indeed problematic. Returning success with an empty payload for a non-existent backup_name is confusing.

This API’s logic is quite tricky. As discussed in #816, the main issue is that this endpoint mixes two responsibilities: returning backup task progress and returning backup metadata.

A PR to improve this is very welcome. Longer term, I think this API should be split into get_backup and get_backup_task.

Thanks for raising this.