Open KeithWong98 opened 9 months ago
Since I was in the code working on some other PRs, I took a quick look at this issue as well, but I could not reproduce.
The expiration code appears to be working as expected - verified via existing unit tests and I added an additional one on my fork trying to reproduce the behavior, but couldn't. I reviewed the relevant code and it appears to be using the psetex redis command everywhere. So it is expected to be setting the ttl with millisecond precision.
@KeithWong98 any additional insights? If you use the pttl or ttl commands via the redis cli what values do you get back?
There is a bug indeed. @ChaimaaeROUAI is going to fix it in via https://github.com/micronaut-projects/micronaut-redis/pull/558
Expected Behavior
If I set the expire-after-write and expire-after-access
I expect the Redis TTL to be set at 24 hours, or 86400 seconds.
Actual Behaviour
The cache TTL value is being set to 86400000 seconds, which is 1000 times the intended amount.
I discovered this after noticing via Redis Insight that the TTL was showing as over 2 years.
I then enabled trace logging on my project, and realized that the value coming back was 86400000 instead of the intended 86400 seconds. Here was the logging output:
It seems to be a problem with converting the value of expireAfterAccess to milliseconds via the
Duration::toMillis
mapping. An example is found here inAbstractRedisCache.java
:It seems the value of
expireAfterAccess
is still being treated as seconds instead of the expected milliseconds.Steps To Reproduce
expire-after-access
andexpire-after-write
withinapplication.yml
to24h
.Environment Information
JDK Version 17
Example Application
No response
Version
4.2.0