Issue in Redis Session Serialization after Upgrading from Spring Boot 3.3.3 to 3.4.3
Description: Hello :) After upgrading from Spring Boot 3.3.3 to 3.4.3, my application encounters an issue where certain sessions stored in Redis no longer include the creationTime attribute. This results in a persistent exception being thrown during request handling:
Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
java.lang.IllegalStateException: creationTime key must not be null
at org.springframework.session.data.redis.RedisSessionMapper.handleMissingKey(RedisSessionMapper.java:62)
at org.springframework.session.data.redis.RedisSessionMapper.apply(RedisSessionMapper.java:72)
at org.springframework.session.data.redis.RedisSessionMapper.apply(RedisSessionMapper.java:37)
at org.springframework.session.data.redis.RedisIndexedSessionRepository.getSession(RedisIndexedSessionRepository.java:535)
at org.springframework.session.data.redis.RedisIndexedSessionRepository.findById(RedisIndexedSessionRepository.java:500)
at org.springframework.session.data.redis.RedisIndexedSessionRepository.findById(RedisIndexedSessionRepository.java:267)
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.getRequestedSession(SessionRepositoryFilter.java:352)
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.getSession(SessionRepositoryFilter.java:286)
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.getSession(SessionRepositoryFilter.java:193)
at jakarta.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:221)
at org.springframework.security.web.context.HttpSessionSecurityContextRepository.lambda$loadDeferredContext$0(HttpSessionSecurityContextRepository.java:143)
at org.springframework.security.web.context.SupplierDeferredSecurityContext.init(SupplierDeferredSecurityContext.java:67)
at org.springframework.security.web.context.SupplierDeferredSecurityContext.get(SupplierDeferredSecurityContext.java:52)
Steps to Reproduce:
Use Spring Boot 3.4.3 with Spring Session Data Redis.
Upgrade from Spring Boot 3.3.3 to 3.4.3.
Start the application and attempt to retrieve a session from Redis.
Observe the IllegalStateException: creationTime key must not be null error.
Expected Behavior:
The session should be deserialized correctly, retaining all required attributes, including creationTime.
Actual Behavior:
Some sessions retrieved from Redis do not contain creationTime, leading to an IllegalStateException.
Workaround:
No known workaround at this time. Clearing Redis storage does not resolve the issue permanently.
Environment:
Spring Boot Version: 3.4.3
Spring Data Session Version: 3.4.2
Java Version: 17
Any additional dependencies or configurations that might be relevant.
Additional Context:
This issue was not present in Spring Boot 3.3.3.
The problem appears to be related to session serialization/deserialization changes in Redis.
Would appreciate any guidance on resolving this issue. Thanks!
Got the same error
seeing those too in my error logs
Got the same error
Did you fine any solution about this please??
seeing those too in my error logs
Any solution about this please?? I had to rollback the migration to the old version
seeing those too in my error logs
Any solution about this please?? I had to rollback the migration to the old version
currently we are only experiencing this issue in a low percentage of requests, we are still on Spring Boot 3.4.3 and monitoring
now solution so far
same error here
Hi,
I was getting the same error with Spring Security and Spring Session Data Redis since upgrading to Spring Boot 3.2.0. You can check my current Spring Boot version via the provided link.
First, I tried marcusdacoregio's answer, but I was still getting the same error.
Then, I found this blog post, and I was able to reproduce the issue and fix it thanks to that. A PR for my project has been merged into my GitHub repository.
I strongly suggest that the Redis cache should be cleared after the fix is deployed.
I hope this helps!