🐛 Fixed broken oembeds on sites with many past embeds#27926
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughThis PR replaces the oEmbed service's per-write unique filename generation with content-addressed storage. The 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Comment |
5859bf2 to
e290571
Compare
ref https://linear.app/tryghost/issue/ONC-1727 processImageFromUrl saves bookmark icons under `images/icon/<basename>`. On sites with many entries sharing a basename, getUniqueFileName walks the accumulated `<basename>-N` tail one S3 HEAD per iteration to find a free slot — linear in the accumulation, easily 60-90s per bookmark on busy publishers. The walk was masked before 7c3ca72 (6.37.0) by a malformed-key bug in S3Storage.exists() that made every uniqueness check return false; once the key was fixed, the walk started actually running. Content-addressing the filename removes the need for the uniqueness check entirely: identical bytes land at the same key, different bytes land at different keys, no walk in either case. It's also the right model for what these files are — a cache of an external resource, where the basename carries no user intent.
e290571 to
523d884
Compare
ref https://linear.app/tryghost/issue/ONC-1727
Root cause
processImageFromUrlsaves bookmark icons underimages/icon/<basename>. On sites with many entries sharing a basename,getUniqueFileNamewalks the accumulated<basename>-Ntail one S3 HEAD per iteration to find a free slot — linear in the accumulation, easily 60-90s per bookmark on busy publishers.The walk was masked before 7c3ca72 (6.37.0) by a malformed-key bug in
S3Storage.exists()that made every uniqueness check return false; once the key was fixed, the walk started actually running.Fix
Content-addressing the filename removes the need for the uniqueness check entirely: identical bytes land at the same key, different bytes land at different keys, no walk in either case. It's also the right model for what these files are — a cache of an external resource, where the basename carries no user intent.
Scope
Only
processImageFromUrlin the oembed service. Other image-saving paths (post uploads, media uploads, site logo, importer, etc.) pass relativetargetDiralready and aren't affected by the walk.