RENAME on cluster connections drops the source key's TTL when keys are in different slots
I maintainer di solito rispondono entro 5 giorni
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 75/100
Direzione di ricerca
Inizia da src/main/java/org/springframework/data/redis/connection/lettuce/LettuceClusterKeyCommands.java, in particolare dall’implementazione di rename(...) collegata nella issue. Segui il percorso tra slot DUMP → RESTORE → DEL e verifica come preservare la scadenza della chiave di origine. Conferma il completamento aggiungendo o aggiornando un test per la rinomina tra slot con una chiave di origine con scadenza.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Java
- Stelle
- 1.9k
- Fork
- 1.3k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di spring-projects/spring-data-redis
-
PathIndexResolver iterates byte[] element-by-element, causing O(n) overheadForse già presa @mp911de l’ha presa 11 giorni fa. Apertatype: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
spring-projects/spring-data-redis#3460 · 1 assegnatario ·
I maintainer di solito rispondono entro 5 giorni
-
status: waiting-for-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
spring-projects/spring-data-redis#3485 ·
I maintainer di solito rispondono entro 5 giorni
-
`JedisConnectionFactory.start()` leaks the pool when `preparePool()` failsForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertastatus: waiting-for-triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
spring-projects/spring-data-redis#3482 · 1 commento ·
I maintainer di solito rispondono entro 5 giorni
-
Release 4.0.9 (2025.1.9)Apertatype: task
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
spring-projects/spring-data-redis#3479 ·
I maintainer di solito rispondono entro 5 giorni
-
Release 4.1.3 (2026.0.3)Apertatype: task
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
spring-projects/spring-data-redis#3478 ·
I maintainer di solito rispondono entro 5 giorni
Tutte le issue di spring-projects/spring-data-redis
Issue simili
-
[BUG] micronaut-serde-oracle-jdbc-json brings a second OJDBC driver onto the runtime classpathForse già presa @ZARAYACH l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
micronaut-projects/micronaut-serialization#1494 · 4 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 2 giorni
-
code-health feature/sync OS/Android QA/Test-Plan-Specified QA/Yes
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
brave/brave-browser#60327 ·
I maintainer di solito rispondono entro 1 giorno
-
Type: Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
it-at-m/raumreservierung#383 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws/context-ontology-accelerator#325 ·
I maintainer di solito rispondono entro 1 giorno