Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#55847 new defect (bug)

Cache does not use expire

Reported by: malthert's profile malthert Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version:
Component: Cache API Keywords:
Focuses: Cc:

Description

By default class-wp-object-cache.php does not use the expire in "function set".

If the request is long (e.g. cron) and the expiration is short (e.g. 30 seconds), this means that expired cache data is used.

WP needs to keep track of expiration times in internal cache too (can be done by storing the time() + $expire time. If time() > that value, the element is expired.

Change History (2)

#1 @SergeyBiryukov
2 years ago

  • Component changed from General to Cache API

#2 @malthert
2 years ago

  • Severity changed from normal to major

This would also require that any external object cache also return their key expirations, as otherwise it would mean that any objects received from an external/permanent object cache are treated as permanent, even though they are not.

The question is basically:

  • cache objects don't expire for the current runtime once they're get/set -> current behavior. this causes issues in long running tasks, e.g. cron

OR

  • cache objects expire even in the current runtime. This means even external object caches need to get the expiration time, if we store it in internal cache

OR

  • only objects set/add with expiration during the current runtime will expire, anything that comes from an external cache is treated as non-expiring for the current runtime. Practically, this probably makes most sense. e.g. if I set something with an expire of 5 seconds, then it will probably expire in the current runtime. If I get it from external, it probably has a longer lifetime (mainly it would also be a major performance drawdown, to check TTL for all external objects)

EDIT:
the problem is also in general, if using an external object cache, and it storing the results from getting it from that backend internally temporary for runtime, then results will be wrong if the permanent backend (redis, memcache,...) changed in the meantime.
This is a general problem with keys and not just expires when using an internal cache helper and is something that is wrong in all permanent object caches I could find for WP

Last edited 2 years ago by malthert (previous) (diff)
Note: See TracTickets for help on using tickets.