Files
seaweedfs/test/s3/lifecycle
Chris Lu 957ac1335c test(s3/lifecycle): integration coverage for ExpirationDate (past)
Rules with Expiration{Date: <past>} route through ScanAtDate in the
engine (decideMode's ActionKindExpirationDate case) — a separate
compile + dispatch branch from the EventDriven delay-group path the
Days-based tests exercise.

Past date + in-prefix object → must expire. Out-of-prefix object →
must remain. Object also backdated as defense-in-depth so the
assertion doesn't depend on whether the dispatcher consults
MinTriggerAge for date kinds.
2026-05-09 23:20:58 -07:00
..

S3 Lifecycle Integration Tests

End-to-end test of the event-driven S3 lifecycle worker, exercised through the s3.lifecycle.run-shard shell command.

Why backdate mtimes?

The S3 API rejects Expiration.Days < 1, so a literal "wait one day" integration test isn't workable. Each test sets up a 1-day expiration rule, puts the target object, then rewrites its filer entry's Mtime to ~30 days ago via filer_pb.UpdateEntry. From the engine's perspective the object is past its expiration window the moment the shell command starts.

Running

# build the binary, start a local mini cluster, run tests, stop it
make test-with-server

# or, if a cluster is already running on the default ports
make test

The test runs the shell command once with -shards 0-15 (one filer subscription covering all 16 shards) rather than computing the target object's shard up front. This keeps the test independent of the ShardID(bucket, key) hash function — only that some shard reaches the deletion within the polling window.

Environment

variable default description
WEED_BINARY required path to weed_binary
S3_ENDPOINT http://localhost:8333 S3 API URL
S3_GRPC_ENDPOINT localhost:18333 S3 gRPC for lifecycle dispatch
MASTER_ENDPOINT http://localhost:9333 master HTTP
FILER_GRPC_ADDRESS localhost:18888 filer gRPC for UpdateEntry