From f9b9bcf95ebe56a0305d35375f571b1eecee2a55 Mon Sep 17 00:00:00 2001 From: Chris Lu Date: Sun, 26 Apr 2026 15:00:04 -0700 Subject: [PATCH] test(s3): conform new test names to TestSSE*Integration so CI runs them The two tests added in the previous commits had names that did NOT match the patterns the test/s3/sse Makefile and .github/workflows/s3-sse-tests.yml use to discover SSE integration tests: - test/s3/sse/Makefile `test` target: TestSSE.*Integration - test/s3/sse/Makefile `test-multipart`: TestSSEMultipartUploadIntegration - .github/workflows/s3-sse-tests.yml: ...|.*Multipart.*Integration|.*RangeRequestsServerBehavior Result: SSE-KMS coverage I added to TestSSERangeReadCoverageMatrix and the Docker-Registry-shape multipart regression in TestSSES3MultipartManyChunks_DockerRegistryShape were silently invisible to CI even though the underlying test setup (start-seaweedfs-ci using s3-config-template.json with the embedded `local` KMS provider) already has SSE-KMS configured. Renames: TestSSERangeReadCoverageMatrix -> TestSSERangeReadIntegration TestSSES3MultipartManyChunks_... -> TestSSEMultipartManyChunksIntegration Both names now match `TestSSE.*Integration` (Makefile `test` target) and TestSSEMultipartManyChunksIntegration additionally matches `.*Multipart.*Integration` (CI's comprehensive subset). No behavior change; only the function names move. Verified locally against `weed mini` with s3-config-template.json: TestSSERangeReadIntegration runs 96 leaf subtests across 4 SSE modes (none, SSE-C, SSE-KMS, SSE-S3) x 3 size classes x 7-9 range patterns, all passing, 0 skipped. The probe-and-skip in the SSE-KMS arm now only fires for ad-hoc local setups that don't load any KMS provider; the project's standard test setup loads the local provider, so CI has full SSE-KMS range coverage. --- test/s3/sse/s3_sse_integration_test.go | 31 +++++++++++++---------- test/s3/sse/s3_sse_range_coverage_test.go | 18 ++++++++----- 2 files changed, 30 insertions(+), 19 deletions(-) diff --git a/test/s3/sse/s3_sse_integration_test.go b/test/s3/sse/s3_sse_integration_test.go index fd0b04a61..b458abcde 100644 --- a/test/s3/sse/s3_sse_integration_test.go +++ b/test/s3/sse/s3_sse_integration_test.go @@ -970,18 +970,18 @@ func uploadAndVerifyMultipartSSEObject(t *testing.T, ctx context.Context, client } } -// TestSSES3MultipartManyChunks_DockerRegistryShape pins the end-to-end fix for -// issue #8908. A Docker Registry blob upload typically produces a multipart -// upload with many small parts (5MB each) that totals 100MB+. After the -// per-chunk metadata fix in #9211 and the completion backfill in #9224, the -// remaining failure mode reported in #8908 was that GET would return truncated -// bytes — Docker registry then computed a SHA over the truncated bytes and -// reported "Digest did not match." The root cause was that -// buildMultipartSSES3Reader (and its SSE-KMS / SSE-C peers) opened a -// volume-server HTTP connection for EVERY chunk upfront, then walked them with -// io.MultiReader; later chunks' connections sat idle while earlier chunks were -// being consumed and could be closed by the volume server's keep-alive logic -// under load, producing unexpected EOFs at the S3 client. +// TestSSEMultipartManyChunksIntegration pins the end-to-end fix for issue +// #8908. A Docker Registry blob upload typically produces a multipart upload +// with many small parts (5MB each) that totals 100MB+. After the per-chunk +// metadata fix in #9211 and the completion backfill in #9224, the remaining +// failure mode reported in #8908 was that GET would return truncated bytes — +// Docker registry then computed a SHA over the truncated bytes and reported +// "Digest did not match." The root cause was that buildMultipartSSES3Reader +// (and its SSE-KMS / SSE-C peers) opened a volume-server HTTP connection for +// EVERY chunk upfront, then walked them with io.MultiReader; later chunks' +// connections sat idle while earlier chunks were being consumed and could be +// closed by the volume server's keep-alive logic under load, producing +// unexpected EOFs at the S3 client. // // This test mirrors that shape: 25 parts of 5MB each (125MB total, 25 // internal chunks since each part is below the 8MB internal chunk size) with @@ -990,7 +990,12 @@ func uploadAndVerifyMultipartSSEObject(t *testing.T, ctx context.Context, client // one volume-server HTTP connection open at a time, which both eliminates the // idle-connection failure mode and makes resource usage proportional to one // chunk regardless of object size. -func TestSSES3MultipartManyChunks_DockerRegistryShape(t *testing.T) { +// +// The function name ends in "Integration" so it is matched by the existing +// `.*Multipart.*Integration` pattern in .github/workflows/s3-sse-tests.yml +// (and the `TestSSE.*Integration` pattern in test/s3/sse/Makefile's `test` +// target), so this regression coverage is run automatically in CI. +func TestSSEMultipartManyChunksIntegration(t *testing.T) { ctx := context.Background() client, err := createS3Client(ctx, defaultConfig) require.NoError(t, err, "Failed to create S3 client") diff --git a/test/s3/sse/s3_sse_range_coverage_test.go b/test/s3/sse/s3_sse_range_coverage_test.go index c8e52514e..d5daef173 100644 --- a/test/s3/sse/s3_sse_range_coverage_test.go +++ b/test/s3/sse/s3_sse_range_coverage_test.go @@ -24,7 +24,7 @@ import ( // and the read path has to stitch keystreams across chunks correctly. const internalChunkSize = 8 * 1024 * 1024 -// TestSSERangeReadCoverageMatrix is the canonical end-to-end coverage matrix +// TestSSERangeReadIntegration is the canonical end-to-end coverage matrix // for HTTP range GETs across SSE modes, object size classes, and range // patterns. It supplements the per-SSE-mode TestSSExxxRangeRequests tests // (which are scoped to small single-chunk objects, ≤1MB) by also exercising @@ -34,11 +34,17 @@ const internalChunkSize = 8 * 1024 * 1024 // pinning range correctness here protects against any future regression in // per-chunk IV / PartOffset plumbing for partial reads. // -// For SSE-KMS, the test probes once with a 1-byte SSE-KMS PUT and skips the -// SSE-KMS subtests with a clear message if the local server has no KMS -// provider configured (the default `weed mini` setup does not include one; -// the Makefile's `test-with-kms` target does). -func TestSSERangeReadCoverageMatrix(t *testing.T) { +// The function name ends in "Integration" so it is matched by the existing +// `TestSSE.*Integration` pattern that the test/s3/sse Makefile and the +// .github/workflows/s3-sse-tests.yml CI flow use to discover SSE integration +// tests; both flows already start the server using s3-config-template.json, +// which configures the embedded `local` KMS provider with on-demand DEK +// creation, so the sse_kms subtests run end-to-end in CI. +// +// For ad-hoc local runs against a server without any KMS provider, the test +// probes once with a 1-byte SSE-KMS PUT and t.Skip's the sse_kms subtree +// with a clear message rather than producing a 5xx-storm in the logs. +func TestSSERangeReadIntegration(t *testing.T) { ctx := context.Background() client, err := createS3Client(ctx, defaultConfig) require.NoError(t, err, "create S3 client")