Options, Meta APIs: Avoid caching options as nonexistent after database errors. - #12595
Options, Meta APIs: Avoid caching options as nonexistent after database errors.#12595gunjanjaswal wants to merge 1 commit into
Conversation
…se errors. A failed `SELECT` in `get_option()` and `get_network_option()` returns null, which is indistinguishable from a missing row. Both functions treated that as proof of non-existence and primed the `notoptions` cache, hiding an option that is still in the database until the cache is invalidated. `delete_option()` had the same problem from the other direction: it primed `notoptions` before checking the result of `$wpdb->delete()`, so a failed delete marked a still-present option as nonexistent. The `notoptions` writes are now gated on the query being known to have succeeded. `delete_network_option()` is adjusted to match: it was guarded on a truthy result, so a successful delete affecting zero rows never primed the cache. Zero rows is a successful query, so it still primes; only false does not.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
1 participant
Trac ticket: https://core.trac.wordpress.org/ticket/61762
$wpdb->get_row()returns null both when an option row is missing and when the query itself failed.get_option()andget_network_option()treated the second case as the first and primed thenotoptionscache, so a transient database error could hide an option that is still in the database. With a persistent object cache that state sticks around, and the option keeps returning its default long after the database has recovered.delete_option()had the same problem from the other direction: it primednotoptionsbefore checking the result of$wpdb->delete(), so a failed delete marked a still-present option as nonexistent.Each
notoptionswrite is now gated on the query being known to have succeeded, using$wpdb->last_erroron the read paths andfalse !== $resulton the delete paths.delete_network_option()was guarded on a truthy result, which meant a successful delete affecting zero rows never primed the cache. Zero rows is a successful query, so it primes there now too.Adds regression tests covering the read and delete paths, including the zero-row case.
Clearing
notoptionsinadd_network_option()andupdate_network_option()is left for a follow-up, per the ticket.