fix(gcs): map cacheControl and customTime on the gRPC object path

[exoego]

Summary

UpdateObject rejected the mask paths. Both are now mapped like their siblings.

A live GCS probe also set the rules: an unset custom_time or null customTime keeps the value, a decrease is rejected, and only contentEncoding is honoured as an upload query parameter.

Type of change

• Bug fix (fix:)
• New feature (feat:)
• Breaking change (feat!: or fix!:)
• Docs / chore

GCP Compatibility

• gRPC GetObject / ListObjects returned an empty cache_control and no custom_time for objects written over REST, and UpdateObject rejected both mask paths. They now maps both fields.
• An unset custom_time under the mask, or a JSON customTime: null, cleared the field. They are now kept.
• A decrease of customTime was accepted. It is now rejected with INVALID_ARGUMENT / 400; the message is pinned in tests.
• An empty cache_control under the mask stored "". It is now unset.
• customTime was stored as sent. It is now rendered in UTC and rejected with 400 if unparsable values.
• System metadata on the upload URL was applied. Only contentEncoding is honoured now.

Checklist

• ./mvnw test passes locally
• New or updated integration test added
• Commit messages follow Conventional Commits

[greptile-apps]

Greptile Summary

The PR aligns GCS REST and gRPC object metadata behavior for cacheControl and customTime.

• Maps both fields through gRPC writes, reads, lists, and update masks.
• Normalizes and validates custom timestamps while preserving GCS decrease and removal semantics.
• Restricts upload URL system metadata to contentEncoding.
• Adds focused controller and integration coverage for metadata round trips and timestamp boundaries.

Confidence Score: 4/5

The PR is not yet safe to merge because malformed custom-time values persisted by older versions can still break object reads and related updates.

Previous finding PRRC_kwDOSgKHVM7rQf9o remains outstanding: stored legacy customTime is still passed into Instant.parse without defensive handling, so malformed persisted metadata can fail gRPC response mapping, and the same unchecked parsing also occurs when comparing an updated custom time. The malformed protobuf timestamp finding was addressed by explicit validation aligned with the newly pinned GCS behavior.

Files Needing Attention: src/main/java/io/floci/gcp/services/gcs/GcsGrpcMapper.java, src/main/java/io/floci/gcp/services/gcs/GcsCustomTime.java

Important Files Changed

Filename	Overview
src/main/java/io/floci/gcp/services/gcs/GcsCustomTime.java	Centralizes REST and gRPC custom-time normalization, range handling, and monotonicity validation.
src/main/java/io/floci/gcp/services/gcs/GcsGrpcMapper.java	Maps cache control and custom time across gRPC object paths, but malformed legacy stored timestamps can still break response mapping.
src/main/java/io/floci/gcp/services/gcs/GcsService.java	Applies normalized custom-time updates without clearing or decreasing an existing value.
src/main/java/io/floci/gcp/services/gcs/GcsUploadController.java	Limits upload URL system metadata to content encoding and validates custom time from JSON metadata.
src/test/java/io/floci/gcp/services/gcs/GcsGrpcControllerTest.java	Covers gRPC metadata round trips, masks, monotonicity, malformed timestamps, and boundary behavior.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  REST[REST upload or patch] --> CT[GcsCustomTime validation]
  GRPC[gRPC write or update] --> CT
  CT --> SVC[GcsService object metadata]
  SVC --> STORE[Stored GcsObjectMeta]
  STORE --> MAP[GcsGrpcMapper]
  MAP --> READ[GetObject and ListObjects]

Loading

_{Reviews (2): Last reviewed commit: "fix(gcs): reject or saturate malformed c..." | Re-trigger Greptile}