Avoid redundant cache misses

[joemcgill]

Description

Generally, when get_option() is called and the option does not exist, WordPress will store the option in the 'notoptions' cache to avoid unnecessary DB requests on subsequent calls to the option. In https://core.trac.wordpress.org/changeset/56595 (shipped in WP 6.4), a change was made to check object cache (when present) before checking the 'notoptions' cache to avoid an unnecessary check of 'notoptions' when the option does exist, but this has been reported to cause an increase in requests to object caches when the option does not exist in https://core.trac.wordpress.org/ticket/62692 if the object cache implementation does not ensure that cache misses avoid redundant calls to the same non-existent option.

In this comment, @rmccue shared a list of implementations affected, including this one.

Even when this is fixed and shipped (hopefully in WP 6.8) people running versions of WP from 6.4–6.7 will still be affected by this bug unless it's handled at the object cache layer.

Expected Behavior

Multiple calls for a nonexistent option in the same request will only result in one request to the Redis backend.

Actual Behavior

Each call for a nonexistent option results in a request to the Redis backend during the same request.

Possible Fix

Update the get() method here so that a cache miss is added to a cached group that is checked before making an external request to Redis for the same key once it's known to result in a cache miss.

Steps to Reproduce

1. Call get_option( 'notexist' ) in a loop. Prior to 6.4, this would generate 2 total cache gets; after 6.4, it generates an infinite number, as each iteration of the cycle triggers a cache get which misses.

Additional context

Environment

• Plugin version:
• PHP version:
• WordPress version: 6.4+

[tillkruss]

I think we'll leave it as is, since the change was reverted. If someone has trouble too many calls, they can use Relay to avoid the load on the cache server.

[joemcgill]

Totally up to you, of course. Just wanted to make sure you were aware that even once the fix for this is shipped in a few months, anyone who hasn't upgraded will still be affected until they catch up to the latest release (which is not an insignificant user base).

Feel free to close this if you're happy with waiting for folks to catch up to a WP Core version that does not have this problem.

[rmccue]

If Relay works similar to our solution and caches misses on each node, then you won't be majorly affected by this either.