Fix fetch_with_batched_keys to respect expires_in option for Redis TTL #2565
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fix
fetch_with_batched_keysto properly set Redis TTL whenexpires_inoption is provided.Problem
Currently,
fetch_with_cache_registerwrites cache entries directly usingredis.setwithout passing theex:parameter, even whenexpires_inis specified. This causes Redis keys to persist indefinitely (TTL = -1), leading to memory growth in self-hosted environments.The existing test passes because
ActiveSupport::Cache::Entrystoresexpires_atinternally and expiration is checked on the Ruby side during deserialization. However, Redis itself never evicts these keys.Changes
ex:option toredis.setwhenexpires_inis providedTesting
Affected Areas
All ~40 call sites of
fetch_with_batched_keyswill now properly respectexpires_in, including:user_learning_object_scopes.rb(already passesexpires_in:but was ineffective)