[jira] [Created] (HDDS-16626) Misleading error message when DaysAfterInitiation is below the configured MPU cleanup threshold

["Prince Raj (Jira)" <ji...@apache.org>]

Prince Raj created HDDS-16626:
---------------------------------

             Summary: Misleading error message when DaysAfterInitiation is below the configured MPU cleanup threshold
                 Key: HDDS-16626
                 URL: https://issues.apache.org/jira/browse/HDDS-16626
             Project: Apache Ozone
          Issue Type: Bug
            Reporter: Prince Raj


h3. Description

While testing the {{PutBucketLifecycleConfiguration}} API for incomplete multipart uploads, I observed that the validation correctly rejects a lifecycle rule when {{AbortIncompleteMultipartUpload.DaysAfterInitiation}} exceeds the configured multipart-upload cleanup threshold.

The lifecycle configuration used was:

 

{{}}
{code:java}
ozones3api put-bucket-lifecycle-configuration \ --bucket "$BUCKET" \ --lifecycle-configuration '{ "Rules": [ { "ID": "expiration-and-abort", "Status": "Enabled", "Filter": { "Prefix": "key1" }, "Expiration": { "Days": 1 }, "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 } } ] }' \ --debug{code}
{{ }}

The cluster was configured with:

 

{{ozone.om.open.mpu.expire.threshold=300s}}

Since the lifecycle rule specifies {{DaysAfterInitiation=1}} day, while the MPU cleanup threshold is configured to 300 seconds (5 minutes), the request is correctly rejected because the background multipart-upload cleanup can remove the upload before the lifecycle rule takes effect.
h3. Current Behavior

The API returns {{InvalidRequest}} with the following message:

 

{{}}
{code:java}
Invalid lifecycle configuration: rule 'abort-incomplete-mpu' has an AbortIncompleteMultipartUpload action with daysAfterInitiation=1 day(s), which is not less than the cluster MPU expire threshold (ozone.om.open.mpu.expire.threshold=300s). The MultipartUploadCleanupService will clean up the upload before the lifecycle rule fires, making the rule ineffective. Set daysAfterInitiation to a value less than 300s, or increase ozone.om.open.mpu.expire.threshold{code}
{{ }}
h3. Problem

The validation is correct, but the remediation suggested in the error message is misleading.

{{AbortIncompleteMultipartUpload.DaysAfterInitiation}} is defined by the S3 lifecycle API as a whole number of {*}days{*}. The value cannot be configured directly in seconds through the S3 lifecycle API.

Therefore, when:

 

{{ozone.om.open.mpu.expire.threshold=300s}}

the recommendation:

 

{{Set daysAfterInitiation to a value less than 300s}}

is not actionable through the S3 lifecycle API. There is no valid lifecycle configuration in which {{DaysAfterInitiation}} can be set to a value such as {{299}} seconds.
h3. Expected Behavior

The API should continue rejecting the lifecycle configuration with {{{}InvalidRequest{}}}, since the configured MPU cleanup threshold can cause the multipart upload to be removed before the lifecycle rule takes effect.

However, the error message should provide remediation that is consistent with the units supported by the S3 lifecycle API.

For example:

 

{{Invalid lifecycle configuration: rule 'abort-incomplete-mpu' has
daysAfterInitiation=1 day(s), but the configured
ozone.om.open.mpu.expire.threshold is 300s.

The MultipartUploadCleanupService may clean up the upload before
the lifecycle rule takes effect.

DaysAfterInitiation must be specified as a whole number of days.
Increase ozone.om.open.mpu.expire.threshold to a value that allows
the configured lifecycle period, or adjust the lifecycle rule.}}

Alternatively, the message could explicitly explain the unit mismatch:

 

{{daysAfterInitiation must be configured in whole days; it cannot be
set to a value below the configured 300-second threshold using the
S3 lifecycle API. Increase ozone.om.open.mpu.expire.threshold to
accommodate the lifecycle period.}}
h3. Expected Result
 * The existing validation behavior should remain unchanged.

 * The API should continue returning {{InvalidRequest}} when the configured lifecycle period cannot take effect before MPU cleanup.

 * The error message should accurately describe the relationship between {{DaysAfterInitiation}} and {{{}ozone.om.open.mpu.expire.threshold{}}}.

 * The remediation guidance should account for the fact that {{DaysAfterInitiation}} is specified in whole days, while the MPU cleanup threshold is configured in seconds.

 * The error message should not recommend setting {{DaysAfterInitiation}} to a value in seconds that cannot be represented through the S3 lifecycle API.

h3. Reproduction
 # Configure the MPU cleanup threshold to a value smaller than one day, for example:

{{ozone.om.open.mpu.expire.threshold=300s}}
 # Create a lifecycle configuration containing:

{{{
  "AbortIncompleteMultipartUpload": \{
    "DaysAfterInitiation": 1
  }
}}}
 # Submit the configuration using {{{}PutBucketLifecycleConfiguration{}}}.

 # Observe that the API returns {{{}InvalidRequest{}}}.

 # Observe that the validation error recommends configuring {{DaysAfterInitiation}} to a value less than {{{}300s{}}}.

 # Note that {{DaysAfterInitiation}} only accepts a whole number of days, making this remediation invalid through the S3 lifecycle API.

h3. Impact

The validation prevents an ineffective lifecycle configuration, but the current error message can mislead users into attempting a configuration that the S3 lifecycle API cannot represent.

The issue is therefore limited to the {*}accuracy and actionability of the validation error message{*}, not the underlying validation logic.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org