Opened 3 years ago
Last modified 3 years ago
#55847 new defect (bug)
Cache does not use expire
Reported by: | 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)
Note: See
TracTickets for help on using
tickets.
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:
OR
OR
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