[#3618] Fix client-side cache invalidation for mixed str and bytes Redis keys #3766
+48 −4
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.
Pull Request check-list
Please make sure to review and check all of these items:
NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.
Description of change
Problem:
Client-side caching in
redis-pywas not consistently invalidating cache entries when Redis keys were passed asbyteswhile stored asstr(or vice versa) as mentioned issue #3618. This caused stale cache values to persist in cases where keys were mixed betweenstrandbytes.Cause:
The
delete_by_redis_keysmethod previously assumed all Redis keys werestrand attempted deletion by encoding bytes to strings. After recent changes that normalized input to bytes, cache entries stored asstrwere no longer being matched, leading to failed deletions.Change / Fix:
delete_by_redis_keysto temporarily support bothstrandbyteskeys:str, it checks the cache for both thestrand UTF-8 encodedbytesversion.bytes, it checks both thebytesand UTF-8 decodedstrversion (if possible).str/bytesscenarios, including overlapping keys and MGET commands.Benefit:
strkeys.Testing:
bytesforstrkeys.strforbyteskeys.