From 155600829ad607b70cebce63606fad2b25b62a0a Mon Sep 17 00:00:00 2001 From: Chris Lu Date: Sat, 9 May 2026 23:07:33 -0700 Subject: [PATCH] test(s3/lifecycle): backdate both versions for NoncurrentDays clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per codex review: NoncurrentDays is clocked from the SUCCESSOR version's mtime (when the displaced version became noncurrent), not from the displaced version's own mtime. Backdating only v1 left the clock (v2's mtime) at "now" and the rule never fired — the test was wrong, not the production path. Backdate v1=31d and v2=30d so v1 sits past the 1-day threshold relative to v2, the noncurrent rule fires, and v2 stays current. --- test/s3/lifecycle/s3_lifecycle_versioning_test.go | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/test/s3/lifecycle/s3_lifecycle_versioning_test.go b/test/s3/lifecycle/s3_lifecycle_versioning_test.go index cd2ba1064..b28700b73 100644 --- a/test/s3/lifecycle/s3_lifecycle_versioning_test.go +++ b/test/s3/lifecycle/s3_lifecycle_versioning_test.go @@ -200,8 +200,13 @@ func TestLifecycleNoncurrentVersionExpiration(t *testing.T) { v2 := aws.ToString(put2.VersionId) require.NotEqual(t, v1, v2) - // Age the noncurrent (v1) past the 1-day threshold. - backdateVersionedMtime(t, fc, bucket, key, v1, 30) + // NoncurrentDays is clocked from the SUCCESSOR's mtime — i.e. when + // the version became noncurrent — not from the displaced version's + // own mtime. Backdating only v1 leaves the noncurrent clock (v2's + // mtime) at "now" and the rule never fires. Age both with v1 older + // than v2 so the ordering is realistic. + backdateVersionedMtime(t, fc, bucket, key, v1, 31) + backdateVersionedMtime(t, fc, bucket, key, v2, 30) out := runLifecycleShard(t) t.Logf("shell output:\n%s", out)