The issue occurs during the deletion of a Third-Party Storage (TPS) DRPolicy. As part of the cleanup process, the code retrieves the S3 profile associated with a DRCluster using Array.find(), but immediately destructures the result without checking whether a matching profile was found.
const s3Profile = ramenS3Profiles.find(
(profile) => profile.s3ProfileName === s3ProfileName
);
const { s3Bucket, s3CompatibleEndpoint, s3Region } = s3Profile;
The fundamental issue is that Array.prototype.find() does not guarantee a return value. It returns either the matching object or undefined if no match exists. Therefore, code should never assume that find() always returns a value. If s3Profile is undefined, the destructuring throws a runtime exception, causing the entire delete workflow to abort.
While a manually modified Ramen ConfigMap could trigger this, a more realistic scenario is a partial failure during a previous delete operation. For example, the cleanup may successfully remove the S3 profile from the Ramen ConfigMap, but fail before deleting the DRCluster due to a transient error such as a network timeout or API failure. When the user retries the delete operation, the S3 profile no longer exists, find() returns undefined, and the retry fails with a runtime exception instead of completing the remaining cleanup.
The recommended fix is to validate the result of find() before using it. If the S3 profile exists, continue with the existing S3-specific cleanup. If it is already missing, simply skip those steps and continue deleting the DRCluster. This follows the Kubernetes principle of idempotent deletion, making the delete workflow resilient to retries and partial failures while avoiding unnecessary runtime exceptions.
The issue occurs during the deletion of a Third-Party Storage (TPS) DRPolicy. As part of the cleanup process, the code retrieves the S3 profile associated with a DRCluster using Array.find(), but immediately destructures the result without checking whether a matching profile was found.
const s3Profile = ramenS3Profiles.find(
(profile) => profile.s3ProfileName === s3ProfileName
);
const { s3Bucket, s3CompatibleEndpoint, s3Region } = s3Profile;
The fundamental issue is that Array.prototype.find() does not guarantee a return value. It returns either the matching object or undefined if no match exists. Therefore, code should never assume that find() always returns a value. If s3Profile is undefined, the destructuring throws a runtime exception, causing the entire delete workflow to abort.
While a manually modified Ramen ConfigMap could trigger this, a more realistic scenario is a partial failure during a previous delete operation. For example, the cleanup may successfully remove the S3 profile from the Ramen ConfigMap, but fail before deleting the DRCluster due to a transient error such as a network timeout or API failure. When the user retries the delete operation, the S3 profile no longer exists, find() returns undefined, and the retry fails with a runtime exception instead of completing the remaining cleanup.
The recommended fix is to validate the result of find() before using it. If the S3 profile exists, continue with the existing S3-specific cleanup. If it is already missing, simply skip those steps and continue deleting the DRCluster. This follows the Kubernetes principle of idempotent deletion, making the delete workflow resilient to retries and partial failures while avoiding unnecessary runtime exceptions.