Set immutable cache-control on R2 media uploads - #54
Conversation
Replace S3FileSystem.writeFile with direct S3.putObject so uploaded objects carry immutable caching metadata. Object keys embed a timestamp and UUID, so content at any URL never changes; caching forever means browsers and the CDN never revalidate avatar/logo/media URLs, and no SWR tags or cache purging are needed. Also sets an explicit Content-Type from the file extension, which writeFile could not express. Drops the S3FileSystem dependency from the upload service since it existed only for bucket writes.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughS3 uploads now use the direct AWS S3 client. The service derives content types from file extensions, applies immutable one-year caching, and removes the S3 filesystem dependency and runtime wiring. ChangesDirect S3 Uploads
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change adds long-lived caching and explicit content types to newly uploaded media while preserving the existing versioned-URL behavior. No actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@greptileai review |
Greptile SummaryThe PR replaces filesystem-backed R2 writes with direct S3 uploads so new profile images, organization logos, and editor media receive explicit content types and one-year immutable cache metadata.
Confidence Score: 5/5The PR appears safe to merge with no concrete blocking or independently actionable issue identified. Current upload callers normalize validated image MIME types to the new mapping’s canonical extensions, direct S3 layer composition remains complete, and timestamp-plus-UUID keys prevent immutable caching from serving overwritten content.
|
| Filename | Overview |
|---|---|
| packages/domain/src/services/s3.ts | Direct S3 uploads consistently provide bucket, body, content type, and immutable cache metadata; existing callers produce supported canonical extensions and generated keys remain unique. |
Reviews (1): Last reviewed commit: "Set immutable cache-control on R2 media ..." | Re-trigger Greptile
Summary
Avatar/logo/editor-media uploads currently go through
S3FileSystem.writeFile, which cannot set object metadata — so nothing carries aCache-Controlheader and browsers/CDN only get weak heuristic caching.Switch to direct
S3.putObjectso every uploaded object carries:Cache-Control: public, max-age=31536000, immutableContent-Typederived from the file extensionObject keys already embed a timestamp + UUID, so content at any given URL never changes. Caching forever is therefore safe: a new avatar just writes a new URL to the database and abandons the old one — no SWR tags, no cache purging, and revalidations stop hitting the bucket after the first fetch per URL.
Changes
packages/domain/src/services/s3.tsfileSystem.writeFilecalls withs3.putObject+CacheControl/ContentTypemetadataS3FileSystemlayer (existed only for bucket writes);S3UploadServiceLivenow providesS3LayerdirectlyNotes
copyObject's default COPY directive, so permanent assets are cached consistently.putObjectwith metadata, unchanged behavior.Verification
packages/domaincheck-types ✅packages/domaintests: 524 passed ✅apps/servercheck-types ✅apps/webastro check: 0 errors ✅Summary by CodeRabbit