Documention says TTL is milliseconds but it's really seconds for Redis

[molund]

I think the documentation for "@strapi-community/plugin-rest-cache": "5.0.0", is wrong.
https://strapi-community.github.io/plugin-rest-cache/guide/provider/redis.html

ttl was set to 600000 and the Redis pods kept running out of memory and crashing. I changed it to 600 and it's behaving as expected. The docs says it’s milliseconds but it’s actually seconds, confirmed using ttl <key> with a stopwatch in redis-cli. (redis:6.2.20-alpine)

This seems to be an issue with version 5.0.0 of the plugin and I think it might only impact Redis, not memory.

      provider: {
        name: "redis",
        options: {
          // The name of the connection as defined in the Redis plugin.
          connection: "default",
          // The time to live in milliseconds. This is the maximum amount of time that an item can be in the cache before it is removed.
          ttl: 3600 * 1000
          // ...
        },
      },

[derrickmehaffy]

Investigated this — you found a real bug, but the diagnosis is inverted: the docs are correct and the code is wrong, and it's worse than a ms/seconds mix-up.

maxAge is milliseconds throughout the plugin (default 3600000). It's passed straight to the provider at recv.js:121, and both providers then multiply by 1000 again before handing it to cache-manager — whose set(key, value, ttl) takes milliseconds.

Reproduced against the versions this repo installs:

intended : 3600000 ms = 1 hour
actual   : 3599999999 ms = 41.7 days
inflation: 1000x

So entries effectively never expire, which is exactly why your Redis pods ran out of memory. Setting ttl: 600 appeared to help because it made the surviving misconfiguration small enough to tolerate — but the underlying * 1000 was still there.

It also affects the memory provider, not just Redis, so this isn't Redis-specific.

Tracking the fix in #126. Thanks for the report and for the ttl <key> stopwatch check — that measurement is what made this findable.

[derrickmehaffy]

Fixed on main by #136 (tracked as #126), shipping in 5.1.0.

To restate the resolution for anyone finding this later: the documentation was correct and the code was wrong. maxAge is milliseconds throughout the plugin, but both providers multiplied it by 1000 again before handing it to cache-manager, whose set() also takes milliseconds. Reproduced against the versions this repo actually installs:

intended : 3600000 ms = 1 hour
actual   : 3599999999 ms = 41.7 days
inflation: 1000x

So entries effectively never expired, which is what exhausted your Redis memory. Setting ttl: 600 appeared to help because it made the surviving misconfiguration small enough to tolerate — the * 1000 was still there underneath.

Two clarifications on the original report:

• It affected the memory provider identically. It was never Redis-specific.
• No configuration change is needed on your side once you upgrade. ttl and maxAge are milliseconds, exactly as the docs say, so 3600 * 1000 in your example is correct and should be left as-is.

The fix also reconciled maxAge, which had disagreed in four places (3600, 3600000, and the boolean true — the last reachable through the public ./types export and yielding a 1 second TTL).

There is now a regression test asserting an entry survives before maxAge and expires after it, running against both providers. There was previously no test covering TTL at all, which is how this shipped.

One thing to be aware of when you upgrade: cached entries will now expire when you tell them to rather than lasting ~41 days, so expect a higher miss rate and more origin traffic than you have been seeing — that is the correct behaviour reasserting itself, not a new problem. If your ttl was tuned around the broken behaviour, it is worth revisiting.

Thanks again for the ttl <key> stopwatch measurement. That is what made this findable.