BUG: Inconsistent TTL on Session Expiration Sets leading to increasing orphaned keys

https://github.com/spring-projects/spring-session/blob/e87be43acb77de4d076cbcffbddff0d281c9edda/spring-session-data-redis/src/main/java/org/springframework/session/data/redis/RedisIndexedSessionRepository.java#L1044

The current implementation of MinuteBasedRedisSessionExpirationStore does not apply a “safety net” Time-To-Live (TTL) to the expiration tracking SET.

Looking at the save method, we can see that the line

this.redis.boundSetOps(expirationsKey).expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);

does not set the expiry when the key is created for the first time. It only updates the TTL for subsequent keys that fall within the same minute.

I assume this behavior is intentional—to refresh the TTL for an already existing SET key. However, the issue is that when the SET is saved for the first time, it has no TTL applied, which can lead to orphaned keys accumulating over time.

The following snippet shows where the TTL should likely be added:

BoundSetOperations<String, Object> expireOperations = this.redis.boundSetOps(expireKey);
expireOperations.add(keyToExpire);

It seems that the following line is missing:

expireOperations.expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);

Could you please confirm if my understanding is correct and whether this could be a potential bug in the implementation?

Start in spring-session-data-redis/src/main/java/org/springframework/session/data/redis/RedisIndexedSessionRepository.java at the MinuteBasedRedisSessionExpirationStore save method around line 1044. Check the first creation of the expiration SET and verify whether its TTL is absent, then confirm the behavior for subsequent entries. Done means newly created expiration tracking SETs receive the intended safety-net TTL without breaking existing refresh behavior.