bug: Inconsistent behavior from Harbor API after deleting a retention policy

[rizul2108]

BUG: Inconsistent behavior in Harbor after deleting a retention policy.

Description
When deleting a retention policy using harbor-cli, the retention ID remains associated with the project metadata even after the policy is deleted. This leads to inconsistent behavior from the Harbor API when handling projects with deleted retention policies.

Steps to Reproduce

1. Create a project asdfghj using harbor-cli. (used the API: createProject)
2. Add a tag retention rule to the project. (used the API: createRetention)
3. Delete the retention policy using harbor-cli. (used the API: deleteRetention)
4. Fetch project details using the Harbor API. (used the API: getProject)

Expected Behavior

• The retention ID should be removed from the project metadata after the retention policy is deleted.

Actual Behavior

• The API response for fetching project details still includes the retention ID of the deleted policy.
• This causes errors when handling projects with deleted retention policies as the retention ID references a non-existent policy.

Possible Cause

• The retention policy ID is not being properly disassociated from the project metadata after deletion.

[bupd]

needs design. TLDR: Harbor's retention deletion is incomplete: It removes the policy, but leaves the project's link to it, causing errors.

[bupd]

As a user, I expect that deleting a retention policy should also remove its association with the project, but that doesn't happen. As a result, the route doesn’t fully implement the intended functionality. https://demo.goharbor.io/#/Retention/deleteRetention - making this route non functional.

[rizul2108]

I was thinking that maybe we can do the following

• first get the projectID from 'ref' field from scope of that retention policy to be deleted
• update metadata of the project with that projectID with the below API
  

[wy65701436]

This is a known issue and is duplicated in GitHub issue #19961.

We should consider cleaning up the project metadata after the relevant resources have been removed from the project.

@rizul2108, could you provide more details on the scenario from your client's perspective? Specifically, how and why does it rely on the metadata of a project?

[rizul2108]

I was working on the tag retention command in harbor-cli and encountered an issue when deleting a retention policy. After deletion, attempting to retrieve retention rules for the same project resulted in an error.

Issue:

• The retention_id remains in the project's metadata after the retention policy has been deleted.
• Since retrieving retention rules requires fetching the retention policy, and the policy ID is obtained from the project's metadata, this leads to an invalid reference.

Client's Perspective:

• The harbor-cli retrieves retention rules by first obtaining the retention policy for a project.
• To do this, it queries the project's metadata to get the retention_id.
• If the retention_id exists in the metadata but the actual policy has been deleted, the request fails because it refers to a non-existent resource.

Proposed Solution:

• Implement a cleanup mechanism to remove the stale retention_id from metadata when a retention policy is deleted.
• Alternatively, modify harbor-cli to handle cases where the retention_id is present in metadata but does not correspond to an existing policy.
• The tool could either:
  • Ignore the stale retention_id and return an appropriate message or
  • Provide an option to clean up the metadata manually.

This behavior is addressed in my PR: [#364.

[github-actions]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.