argoproj/argo-workflows · error

markInfrequentAccessAfterDays cannot be large than markDelet

Error message

markInfrequentAccessAfterDays cannot be large than markDeletionAfterDays

What it means

Argo Workflows' OSS artifact lifecycle configuration maps a user-specified lifecycle rule onto an Alibaba Cloud OSS bucket rule: objects transition to Infrequent Access storage after MarkInfrequentAccessAfterDays days and are deleted after MarkDeletionAfterDays days. For the lifecycle to make sense, the IA transition must happen at or before deletion. The controller validates this in setBucketLifecycleRule (workflow/artifacts/oss/oss.go:374) and refuses to build the rule when markInfrequentAccessAfterDays > markDeletionAfterDays, returning this error instead of sending an inconsistent rule to OSS.

Source

Thrown at workflow/artifacts/oss/oss.go:375

		}
	}
	return nil
}

func setBucketLifecycleRule(client *oss.Client, ossArtifact *wfv1.OSSArtifact) error {
	if ossArtifact.LifecycleRule.MarkInfrequentAccessAfterDays == 0 && ossArtifact.LifecycleRule.MarkDeletionAfterDays == 0 {
		return nil
	}
	var markInfrequentAccessAfterDays int
	var markDeletionAfterDays int
	if ossArtifact.LifecycleRule.MarkInfrequentAccessAfterDays != 0 {
		markInfrequentAccessAfterDays = int(ossArtifact.LifecycleRule.MarkInfrequentAccessAfterDays)
	}
	if ossArtifact.LifecycleRule.MarkDeletionAfterDays != 0 {
		markDeletionAfterDays = int(ossArtifact.LifecycleRule.MarkDeletionAfterDays)
	}
	if markInfrequentAccessAfterDays > markDeletionAfterDays {
		return fmt.Errorf("markInfrequentAccessAfterDays cannot be large than markDeletionAfterDays")
	}

	// Delete the current version objects after a period of time.
	// If BucketVersioning is enbaled, the objects will turn to non-current version.
	expiration := oss.LifecycleExpiration{
		Days: markDeletionAfterDays,
	}
	// Convert to Infrequent Access (IA) storage type for objects that are expired after a period of time.
	transition := oss.LifecycleTransition{
		Days:         markInfrequentAccessAfterDays,
		StorageClass: oss.StorageIA,
	}
	// Delete the aborted uploaded parts after a period of time.
	abortMultipartUpload := oss.LifecycleAbortMultipartUpload{
		Days: markDeletionAfterDays,
	}

	keySha := fmt.Sprintf("%x", sha256.Sum256([]byte(ossArtifact.Key)))

View on GitHub (pinned to 35bff19146)

Solutions

  1. Set lifecycleRule.markDeletionAfterDays to a value >= lifecycleRule.markInfrequentAccessAfterDays (e.g. IA at 7, delete at 30).
  2. If you do not want an IA transition at all, remove markInfrequentAccessAfterDays or set it to 0.
  3. Check for swapped values in the workflow spec and exchange the two numbers.
  4. If only IA transition is desired, note this API always configures deletion too; pick a large markDeletionAfterDays value explicitly.

Example fix

// before (workflow spec)
lifecycleRule:
  markInfrequentAccessAfterDays: 30
  markDeletionAfterDays: 7
// after
lifecycleRule:
  markInfrequentAccessAfterDays: 7
  markDeletionAfterDays: 30
Defensive patterns

Strategy: validation

Validate before calling

if lc := wf.Artifacts["x"].OSS.LifecycleRule; lc != nil && lc.MarkInfrequentAccessAfterDays != 0 && lc.MarkInfrequentAccessAfterDays > lc.MarkDeletionAfterDays {
    return fmt.Errorf("markInfrequentAccessAfterDays (%d) must be <= markDeletionAfterDays (%d)", lc.MarkInfrequentAccessAfterDays, lc.MarkDeletionAfterDays)
}

Prevention

When it happens

Trigger: Registering an OSS artifact with lifecycleRule.markInfrequentAccessAfterDays greater than lifecycleRule.markDeletionAfterDays (e.g. markInfrequentAccessAfterDays: 30, markDeletionAfterDays: 7). Also triggered when only markInfrequentAccessAfterDays is set: markDeletionAfterDays defaults to 0, so any positive IA value exceeds it. The error surfaces while the artifact driver configures the bucket during artifact save.

Common situations: Users copying an S3-style lifecycle config where expiration rules differ; typos swapping the two fields; assuming the fields are independent like raw OSS console rules; setting only the IA transition field and not realizing deletion defaults to 0; renaming/reordering fields between Argo versions and misassigning values.

Related errors


AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03). Data as JSON: /api/errors/01cf223f352b77ba. Report an issue: GitHub.