This allows us to have different cache controls depending on whether
you're viewing your own avatar, or someone else's. Your own avatar will
always be fresh, while other folks' avatars can be pulled from the CDN.
When ActiveStorage::Record uses `connects_to` for read replica support,
it creates a separate connection pool from ApplicationRecord. This causes
`after_commit` callbacks to fire in non-deterministic order - the
Attachment's `create_variants` callback can fire before the User model's
upload callback completes, resulting in FileNotFoundError.
The fix removes replica connection configuration from ActiveStorage::Record
so it shares the same connection pool as application models, ensuring
proper callback ordering.
Also reverts test workarounds that were added to work around this issue,
since the root cause is now fixed.
See: https://github.com/rails/rails/issues/53694
Process variants synchronously on attachment to close the window between
image upload and variant availability, guaranteeing that we won't have
lazy variant processing attempts in GET requests.
Tradeoff is that we do variant processing in upload requests, which is
actually desirable. We're working with images that should take
milliseconds to resize given that we'll already have the file on hand.
References https://github.com/rails/rails/pull/51951
- redirect avatar image requests to the rails_blob_url, instead of
streaming them through the web app
- use a thumbnail variant for avatar images
- only put avatar initials behind the stale? check (not the image
redirect, which would result in browsers rendering broken images when
an avatar is changed, until max-age expires)
Locally, having stale_while_revalidate works great, but in production when we are behind CloudFlare, this results in an old image being shown after you upload a new one
See: https://app.fizzy.do/5986089/cards/2978
Kevin McConnell