[bug - 2.0.0] Redis keys TTL do not respect `revalidate` configurations

[fturmel]

Reproducible with the redis-minimal example provided in the project. None of the revalidate settings are being applied, they always default to 1.5 years.

You can still control the values globally in the cache handler, but obviously we need granular control.

[fturmel]

Nevermind, I need to familiarize myself better with Next's caching internals. It seems to behave correctly but the TTLs on the keys took me by surprise. I did not anticipate that the stale values would be so high by default, and I couldn't manage to find where the revalidate values were stored (they must be inferred between the different timestamps). Sorry about the noise!

See below...

[fturmel]

I'm reading the @neshca/cache-handler docs (assuming this is still supposed to be compatible) and I do think something is wrong with the TTLs after all.

The estimateExpireAge callback parameter staleAge is supposed to represent the revalidate value when one has been set. It never does though, and only seems to match the defaultStaleAge.

// on the page.tsx
export const revalidate = 3600; // 1h

// in the cache handler
const config = {
  handlers: [redisCacheHandler],
  ttl: {
    estimateExpireAge: (staleAge) => {
      console.log(staleAge); // 31536000 (1 year). 3600 should supersede defaultStaleAge here!
      return staleAge * 1.5; // the return value gets correctly applied
    },
  },
};

This means the stale TTLs are never proportional to the revalidate values as intended! A route with a short revalidate of 10 seconds would end up with a stale value of 1.5 years instead of the expected proportional 15 seconds. And the cache entries would be kept in memory for all this time instead of being purged.

[AyronK]

Thanks for the issue, I need to take time to understand what could be wrong here and where this bug could slip through, compare it with 1.3.2 and with neschca. If you have more leads, please share.

[fbudassi]

I can confirm the bug seems to be happening. I'm just starting my migration from the original neshca v1.9 to fortedigital v2.0 (because I'm also migrating to next 15), and looking at the redis keys, they are using the defaultStaleAge.

For instance, this particular entry should have a ttl of 15 mins:

[AyronK]

What I have found so far is that this bug:

• affects full page cache (not enough data yet to confirm if this is always true or a conditional fault)
• affects fetch cache only if no tags are used

I'll be looking at why this happens, stay tuned :)

[AyronK]

I got this!