Add HEAD method support to S3v2 presign URL

What does this MR do?

Adds the missing case http.MethodHead branch to PresignURL() in cache/s3v2/s3.go, using the AWS SDK v2 PresignHeadObject API.

Why was this MR needed?

Commit 826a555 introduced GetHeadURL() as part of the FF_HASH_CACHE_KEYS feature (cache key renaming). It correctly added the method to the Adapter interface and wired it up in s3v2/adapter.go, but the inner PresignURL() switch in s3.go was never updated to handle http.MethodHead.

As a result, every call to GetHeadURL() with FF_HASH_CACHE_KEYS=true falls through to the default: case:

return cache.PresignedURL{}, fmt.Errorf("unsupported method: %s", method)

This is a silent failure: the runner logs ERROR: error while generating S3 pre-signed URL error=unsupported method: HEAD to its own output (not the job trace), the cache rename is silently skipped, and the job reports success. Users enabling FF_HASH_CACHE_KEYS on an existing project will never have their old cache objects migrated to hashed keys.

What's the best way to test this MR?

Unit tests (automated):

Two additions to cache/s3v2/s3_test.go:

  1. TestS3Client_PresignURL extended: after the existing PUT+GET round-trip, presigns a HEAD and asserts the mock S3 server returns HTTP 200.
  2. TestS3Client_PresignURL_UnknownMethodError: verifies the default: branch still fires an error for genuinely unsupported methods.
go test ./cache/s3v2/... -run TestS3Client

Manual reproduction (confirmed live):

  • Buggy binary (upstream main): runner logs ERROR: error while generating S3 pre-signed URL error=unsupported method: HEAD on every job with FF_HASH_CACHE_KEYS=true.
  • Fixed binary (this branch): the same job completes cleanly with no error.

What are the relevant issue numbers?

Closes #39386 (closed)

Edited by Sepehr Heydari

Merge request reports

Loading