RENAME on cluster connections drops the source key's TTL when keys are in different slots
Maintainers usually reply within 8 days
@mp911de is already working on this.
Since Oct 22, 2026.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
Research direction
Start with src/main/java/org/springframework/data/redis/connection/lettuce/LettuceClusterKeyCommands.java, especially the rename(...) implementation linked in the issue. Trace the cross-slot DUMP → RESTORE → DEL path and check how the source key’s expiry can be preserved. Confirm done by adding or updating a test for renaming across slots with an expiring source key.
Written by the indexing model from the issue text.
Description
Summary
When the source and target keys hash to different slots, LettuceClusterKeyCommands.rename(...) doesn't send RENAME. Instead it emulates it with DUMP -> RESTORE -> DEL. The RESTORE call passes a hard-coded TTL of 0, so the target key ends up without an expiry, even when the source key had one:
As a result, when we rename a key to a diffferent slot, the key loses its TTL.
Question
Is the hard-coded 0 TTL intentional? Or should the emulation keep the source key's TTL?
If dropping the TTL isn't intended, I'd like to propose a fix and open a PR.
- Dominant language
- Java
- Stars
- 1.9k
- Forks
- 1.3k
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from spring-projects/spring-data-redis
-
PathIndexResolver iterates byte[] element-by-element, causing O(n) overheadPossibly taken @mp911de claimed this 10 days ago. Opentype: bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
spring-projects/spring-data-redis#3460 · 1 assignee ·
Maintainers usually reply within 8 days
-
`JedisConnectionFactory.start()` leaks the pool when `preparePool()` failsPossibly taken @night-crawlr claimed this today. Openstatus: waiting-for-triage
Difficulty 3/5 1-2 days Newbie friendliness 35/100
spring-projects/spring-data-redis#3482 ·
Maintainers usually reply within 8 days
-
type: task
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
spring-projects/spring-data-redis#3479 ·
Maintainers usually reply within 8 days
-
type: task
Difficulty 4/5 3-5 days Newbie friendliness 25/100
spring-projects/spring-data-redis#3478 ·
Maintainers usually reply within 8 days
-
type: task
Difficulty 5/5 Over a week Newbie friendliness 20/100
spring-projects/spring-data-redis#3477 ·
Maintainers usually reply within 8 days
All issues in spring-projects/spring-data-redis
Similar issues
-
priority: p2 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
googleapis/java-genai#1372 ·
Maintainers usually reply within 1 day
-
GeoSeries scale and skew tests fail with pytest 9.2.0Possibly taken @jiayuasu claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
priority: medium Review effort [1-5]: 3 status: needs-triage type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
carlos-emr/carlos#5431 ·
Maintainers usually reply within 1 day
-
Integration tests: jetty:run fails with WELD-001408 for CountryJpaServicePossibly taken @viniciusmachak claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
primefaces/primefaces#15431 ·
Maintainers usually reply within 1 day
-
test(multi-tenancy): assert cross-tenant vulnerability reads are refused in the CWE isolation testOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OpenAEV-Platform/openaev#8792 ·
Maintainers usually reply within 2 days