Improve Error Handling in Purge Path

[estebanreyl]

Description

The current error handling in the purge deletion path does not adequately distinguish between different types of HTTP errors. This can lead to unnecessary overall failures or missed retry opportunities. We should enhance the logic to respond appropriately based on the HTTP status codes returned by the registry.

Proposed Improvements

1. Handle HTTP 429 (Too Many Requests)

   • Implement backoff and retry logic to reduce request frequency when rate-limited.

2. Handle HTTP 500/502/503 (Internal Server Errors)

   • Retry such errors with backoff, treat as transient
   • Consider safe to ignore without terminating the operation even if we fail
   • Log and continue processing other items

3. Handle HTTP 404 (Not Found)

   • Consider safe to ignore; no retry needed. (Already implemented)

4. Handle HTTP 401 (Unauthorized) and 403 (Forbidden)

   • Treat as hard failures.
   • Log clearly and halt the operation.
   • If authentication has failed there is no expectation that the next request it will succeed

5. Handle Other Status Codes

   • 405 (Method Not Allowed): Investigate and define appropriate handling.
   • 400 (Bad Request): Likely indicates a client-side issue; log and skip.
   • 502/503 (Bad Gateway/Service Unavailable): Treat as transient; retry with backoff.
   • Log unexpected status codes with enough context for debugging.

Tasks

• Audit current error handling logic in the purge path.
• Implement differentiated handling for 429, 500, 404, 401, 403, and other relevant status codes.
• Add retries with exponential backoff where appropriate.
• Improve logging to clearly indicate the type of error and the action taken.
• Update CLI documentation and usage guidance if behavior changes.