Chris LuandDevin
bf3081e23a
* s3lifecycle: schedule ExpirationDays from version-file writes On a versioned bucket a PUT lands in the meta-log as the version file plus the .versions/ directory update — there is no bare-key event, so the version-folder skip dropped every version-file event for all kinds but ExpiredDeleteMarker. ExpirationDays therefore only fired via the recovery walker's cold-start / rule-change pass: once a shard had a saved cursor, no daily run ever scheduled another delete marker. A version-file write is the latest for its logical key at write time, so route it through the same event-driven evaluation the regular path runs. The match carries the file's identity with an empty VersionID — the dispatcher resolves the current latest at due time, and a fresher PUT meanwhile resolves to STALE_IDENTITY there. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> * lifecycle test: versioned Expiration fires on the second daily run Establishes the shard cursor with a first pass, then PUTs and backdates a new versioned object and runs again. The delete marker must appear without a rule change forcing a recovery walk. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> * ci: run TestLifecycleVersionedBucketExpiresOnSecondRun in the lifecycle matrix --------- Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
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 |