Upgrade/Install: Retry an update check whose result could not be stored. - #12596

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props gunjanjaswal, adamsilverstein, siliconforks, madhazelnut.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Test using WordPress Playground

The 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

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Questions:

• Can we just continue with the update in _maybe_update_core when the transient is missing?
• Can we fix the underlying issue that prevents the transient from being set correctly in the first place instead of papering over it?

Thanks Adam, the other two are worth answering directly.

On continuing in _maybe_update_core() when the transient is missing: that would help core auto-updates, but it doesn't cover the reported failure. The stale last_checked blocks the check itself for plugins and themes too, and it's what makes the admin screens report the site as up to date while it quietly stops receiving updates. _maybe_update_core() is one consumer downstream of that; resetting the lock restores all three paths at once, rather than patching a single caller.

On fixing the underlying issue instead: I'd gently push back that there isn't one bug to fix here, it's a class of storage failures core can't fully prevent. Whether the payload stores depends on the environment: a non-utf8mb4 column choking on a 4-byte character, an object cache backend returning false, a write failing under load. What core can own is that a transient storage failure doesn't become a permanent one. Today a single failed write locks the site out of all updates, security releases included, until someone notices and clears the transient by hand. If the ticket turns up a specific reproducible cause worth fixing on top of this, I'm glad to take that separately, but it wouldn't remove the need to fail safe when the write doesn't land.

Happy to swap the immediate retry for a short backoff too if resetting straight to 0 reads as too eager.

I'd gently push back that there isn't one bug to fix here, it's a class of storage failures core can't fully prevent. Whether the payload stores depends on the environment: a non-utf8mb4 column choking on a 4-byte character,

Right - I'm not arguing against having better error handling, but rather avoiding the error entirely for the class of issues the ticket was opened for - caused as I understand it by the use of a "4 byte character" emoji in their changelog.

Are these characters winding up as part of the transient data, and if so can we strip these problematic characters from the data before trying to set the transient since we know they may cause an issue? Then the transient set wouldn't fail and everything would work as expected, correct?

Right - I'm not arguing against having better error handling, but rather avoiding the error entirely for the class of issues the ticket was opened for - caused as I understand it by the use of a "4 byte character" emoji in their changelog.

Are these characters winding up as part of the transient data, and if so can we strip these problematic characters from the data before trying to set the transient since we know they may cause an issue? Then the transient set wouldn't fail and everything would work as expected, correct?

@adamsilverstein have you seen my PR #13282? It basically attempts to do this.

@gunjanjaswal - Thanks for your contribution here. Please note that while it is absolutely fine to make AI driven contributions including writing, the WordPress project policy is that you attribute that writing or code so it is clear. Adding a simple line at the top such as "This response written by Claude" is sufficient. See https://make.wordpress.org/ai/handbook/ai-guidelines/ for additional details.

@adamsilverstein have you seen my PR #13282? It basically attempts to do this.

Oh great, thanks for sharing that @siliconforks

Thanks Adam, and no problem on the disclosure, I've added a note to the description.

On the emoji case: yes, those 4-byte characters land in the changelog/response payload that goes into the transient, and stripping them before the write is a sound fix for that specific trigger. @siliconforks' #13282 looks like the right home for it.

I'd frame the two as complementary rather than either/or. Stripping prevents the known emoji case, but the same permanent lockout happens whenever a store fails for a reason sanitizing can't reach: an object cache backend returning false, a write failing under load, a value that's valid but rejected by a filter. This PR is the fail-safe under all of those. It notices the store didn't land and lets the next request retry, instead of the site going quiet until someone clears the transient by hand. Happy to rebase around #13282 if it merges first; the retry path sits independently of how the payload is built.

@adamsilverstein gentle nudge on this when you get a chance — I folded in your earlier feedback, so it should be ready for another look. No rush, just keeping it on your radar.

Thanks for the nudge @gunjanjaswal - I'll take another look soon!

Looking at this PR, I confess I don't entirely understand what it is intended to do. It appears to be attempting to detect errors and then reset the last_checked timestamp to 0. But that doesn't really fix anything - in fact, it just seems to make the problem worse:

• Before, the check for updates might fail, but it would update the timestamp, so it would not check again for N hours (or whatever the timeout is).
• With this PR, it's going to be checking for updates, failing to store the transient, and setting the timestamp to 0, so it will immediately check for updates again, presumably fail to store the transient again, and so on, continuously. So now you have a potential performance problem in addition to the problem of not getting updates.

This PR also logs a message when an error is detected. In principle I agree that this is a good idea, but currently there doesn't seem to be a reliable way to do this. The problem is that set_site_transient() doesn't really have a way of signalling errors - if it returns false, that might indicate an error, or it might simply be that the transient was already set to the requested value. This PR attempts to work around that by trying to detect the latter case, but that is going to be prone to race conditions.

It seems fairly easy to trigger the race condition with WP-CLI using the following steps:

1. Apply this PR.

2. Make sure you have some plugins installed. (It's probably best to have several plugins installed as it will probably make the update check take longer and be more likely to trigger the race condition.)

3. Delete the update_plugins transient:

   wp transient delete --network update_plugins
   

4. Run two simultaneous update checks:

   wp plugin update --dry-run --all & wp plugin update --dry-run --all
   

In my testing this seems to trigger the race condition at least 50% of the time, and you will get a spurious error message: "The result of the plugin update check could not be stored. The check will run again on the next request."

You're right on both counts, thanks for the careful analysis — I've reworked it.

The busy loop. Resetting last_checked to 0 does turn a persistent storage failure into a per-request re-check, which is worse than the stale-lock behaviour it was trying to fix. I've dropped the reset (and the _wp_maybe_reset_update_check_lock helper) entirely. The lock now expires on its own timeout exactly as before — the change no longer touches recovery timing at all.

The false-return race. Agreed that a false return can't distinguish a failed write from an unchanged value, and comparing the payload to the pre-fetch lock is racy under concurrency, as your WP-CLI repro shows. The warning now keys off $wpdb->last_error instead: a genuine write failure sets it, while an unchanged write runs no query and sets nothing, so the concurrent-checks case stays silent. That should remove the spurious message from your repro — if you get a chance to run it again against the updated branch I'd be glad to know it's clean on your end too.

So the PR is now scoped down to just surfacing a real storage failure as a warning, rather than trying to auto-recover from it. That keeps the diagnostic value @adamsilverstein liked without the retry loop or the race.

Now that the PR scope is reduced to error messages, it doesn't seem to solve the original issue reported in https://core.trac.wordpress.org/ticket/64550 where updates break if the transient can't be stored. We should keep looking into this, there should be a way to resolve the issue.

Fixing the issue in https://core.trac.wordpress.org/ticket/64550 is the goal of PR #13282. This PR - PR #12596 - just improves the error detection and handling.

Thanks @siliconforks and @gunjanjaswal for all the back and forth here. I think the cleanest path forward is to encode the problem characters before we store the transient, so the write never fails in the first place.

Claude dug into both PRs and the wpdb code path, here is the approach it suggests:

When the option_value column isn't utf8mb4, wpdb::process_fields() rejects the whole write as soon as the payload contains a 4-byte character (see strip_invalid_text() in class-wpdb.php). The lock copy with a fresh last_checked is all that's left, so the site reports itself up to date until the next check fails the same way.

Rather than detecting the failure after the fact, the payload could be encoded before it is written. wp_update_plugins() already runs a $sanitize_plugin_update_payload closure right before set_site_transient(); that closure (plus an equivalent for themes and core) could convert any 4-byte characters to numeric HTML entities when the storage column isn't utf8mb4:

$table   = is_multisite() ? $wpdb->sitemeta : $wpdb->options;
$column  = is_multisite() ? 'meta_value' : 'option_value';

if ( 'utf8mb4' !== $wpdb->get_col_charset( $table, $column ) ) {
	$updates = map_deep(
		$updates,
		static function ( $value ) {
			if ( ! is_string( $value ) ) {
				return $value;
			}
			return preg_replace_callback(
				'/[\x{10000}-\x{10FFFF}]/u',
				static function ( $matches ) {
					return '&#x' . dechex( mb_ord( $matches[0] ) ) . ';';
				},
				$value
			);
		}
	);
}

A few reasons this seems like a better fit than the current approaches:

• Nothing is lost. Changelogs and upgrade notices are rendered as HTML, so the emoji still display, where stripping them (as Sanitize 'update_plugins' and 'update_themes' transients. #13282 does) removes them.
• It catches every 4-byte character, not just the ones in wp_encode_emoji()'s list.
• It checks the right table on multisite, where site transients live in sitemeta.meta_value rather than options.option_value. Sanitize 'update_plugins' and 'update_themes' transients. #13282 currently checks $wpdb->options in both cases.
• It covers update_core too, not only plugins and themes.
• There is precedent: wp_insert_post() already encodes emoji on utf8 tables, and sanitize_option() encodes before stripping for blogname/blogdescription.
• No race, no retry loop, and no reliance on set_site_transient() returning false or on $wpdb->last_error, which can be stale when the write short-circuits without running a query.

Worth noting this only addresses the charset trigger from the ticket. A backoff on last_checked (retry in an hour instead of twelve, rather than resetting to 0) could still be a reasonable follow up for other storage failures, but it doesn't need to block the root cause fix.

@siliconforks would you be up for reworking #13282 along these lines? @gunjanjaswal happy to have you collaborate there too, or pick up the backoff piece separately. What do you both think?

Claude dug into both PRs and the wpdb code path, here is the approach it suggests:

When the option_value column isn't utf8mb4, wpdb::process_fields() rejects the whole write as soon as the payload contains a 4-byte character (see strip_invalid_text() in class-wpdb.php). The lock copy with a fresh last_checked is all that's left, so the site reports itself up to date until the next check fails the same way.
Rather than detecting the failure after the fact, the payload could be encoded before it is written. wp_update_plugins() already runs a $sanitize_plugin_update_payload closure right before set_site_transient(); that closure (plus an equivalent for themes and core) could convert any 4-byte characters to numeric HTML entities when the storage column isn't utf8mb4:

$table   = is_multisite() ? $wpdb->sitemeta : $wpdb->options;
$column  = is_multisite() ? 'meta_value' : 'option_value';

if ( 'utf8mb4' !== $wpdb->get_col_charset( $table, $column ) ) {
	$updates = map_deep(
		$updates,
		static function ( $value ) {
			if ( ! is_string( $value ) ) {
				return $value;
			}
			return preg_replace_callback(
				'/[\x{10000}-\x{10FFFF}]/u',
				static function ( $matches ) {
					return '&#x' . dechex( mb_ord( $matches[0] ) ) . ';';
				},
				$value
			);
		}
	);
}

I see a few things worth noting about Claude's suggested code above:

1. It assumes that the content of the update fields is always HTML. That might not always be the case, although it may be reasonable to simply assume that it is and that you can just use HTML entities.

2. It assumes that transients are always stored in the database. This means it ends up running the sanitization code even if there is no need for it because transients are being stored elsewhere. (The current approach in PR #13282 only runs if transients are being stored in the database.)

3. It assumes that, if the database character set is not utf8mb4, then it must be utf8mb3. That's probably the most likely scenario in 2026 (if a WordPress site isn't using at least utf8mb3, then there are probably other things broken besides just updates). Still, in theory the current approach in PR #13282 should work even if the database character set is something other than utf8mb3. (I haven't tested it with anything other than utf8mb3 though.)

I'm not sure if any of those are worth worrying about in practice. Thoughts?

I also note that Claude seems to be hallucinating in some places here:

• Nothing is lost. Changelogs and upgrade notices are rendered as HTML, so the emoji still display, where stripping them (as Sanitize 'update_plugins' and 'update_themes' transients. #13282 does) removes them.

Again, I don't think you can necessarily be certain that the content is HTML (though it may be reasonable to just assume that it is).

• It catches every 4-byte character, not just the ones in wp_encode_emoji()'s list.

This seems like a hallucination: PR #13282 does not use wp_encode_emoji() at all. (Possibly Claude is looking at the approach used for sanitizing blogdescription and blogname?)

• It checks the right table on multisite, where site transients live in sitemeta.meta_value rather than options.option_value. Sanitize 'update_plugins' and 'update_themes' transients. #13282 currently checks $wpdb->options in both cases.

Again, this seems like a hallucination: PR #13282 does not check $wpdb->options at all.

• It covers update_core too, not only plugins and themes.

I'm not sure whether this is actually worth doing for core updates, as they seem unlikely be affected by this issue.

• There is precedent: wp_insert_post() already encodes emoji on utf8 tables, and sanitize_option() encodes before stripping for blogname/blogdescription.

One difference is that those are known to always be HTML.

• No race, no retry loop, and no reliance on set_site_transient() returning false or on $wpdb->last_error, which can be stale when the write short-circuits without running a query.

I'm not sure this eliminates the need to check for errors - it may still be a good idea to check for errors anyway.

Hallucinations aside, Claude's basic proposal seems reasonable. I can rework PR #13282 along those lines if you think that's the best approach.

I'm not sure this eliminates the need to check for errors - it may still be a good idea to check for errors anyway.

As long as we can reliably detect them, adding makes sense.

Again, I don't think you can necessarily be certain that the content is HTML (though it may be reasonable to just assume that it is).

Hmm, good point. It would be good to cover this in a test to confirm or change expected behavior.

Again, this seems like a hallucination: #13282 does not check $wpdb->options at all.

Oh - some of the hallucinations may have been from an earlier part of my session with Claude exploring several possible approaches to fixing the underlying issue. I should have kept the final comment free of those.

I'm not sure whether this is actually worth doing for core updates, as they seem unlikely be affected by this issue.

Right, we only need this for themes and plugins!

It assumes that, if the database character set is not utf8mb4, then it must be utf8mb3. That's probably the most likely scenario in 2026 (if a WordPress site isn't using at least utf8mb3, then there are probably other things broken besides just updates). Still, in theory the current approach in #13282 should work even if the database character set is something other than utf8mb3. (I haven't tested it with anything other than utf8mb3 though.)

Hmm, I reviewed the approach in #13282 again and actually think its better than what Claude is proposing here. lets stick with what you have. Thanks for reviewing the suggestion anyway.

On the "as long as we can reliably detect them" point, I went through the write path for the charset case and I think detection holds up here. When a 4-byte character hits a non-utf8mb4 column, wpdb doesn't fail at the query. It fails before the query runs:

• strip_invalid_text() builds its validation regex with the 4-byte sequences included only when the column charset is utf8mb4. On a utf8/utf8mb3 column those bytes fall through to the catch-all and get stripped, so the converted string no longer matches the input.
• process_fields() sees $data !== $converted_data, sets $wpdb->last_error to "Processing the value for the following field failed: option_value…", and returns false.
• update() gets that false and returns before it ever calls query().

So on this exact path last_error is set, and it's set by process_fields() itself rather than carried over from a query. That's the reverse of the "it can be stale when the write short-circuits without running a query" concern: the error is written precisely because no query runs. And every query() runs flush(), which clears last_error, so the successful get_option read that happens just before the write leaves it empty going in. The check isn't catching a leftover from something earlier.

That fits the direction you landed on: #13282 stays the root-cause fix (encode before storing, nothing dropped), and this PR is the detection layer for storage failures #13282 doesn't head off.

One thing I'd like to tighten based on your note about covering it in a test: I can make the failing-write test exercise the real path instead of the simulated one. pre_get_col_charset lets a test force option_value to utf8mb3, so an update check whose payload carries an emoji gets rejected by wpdb for real and the warning fires, no schema surgery needed. Happy to add that here if you'd like it in.

The check isn't catching a leftover from something earlier.

One issue I see with the last_error check is that it assumes that transients are being stored in the database, which may not necessarily be the case. This means it might be detecting a database error occurring previously somewhere else that has nothing to do with updates.

To demonstrate this, perform the following steps:

1. Install an object cache (e.g., using memcached)

2. Install and activate this simple plugin:

   <?php
   
   /*
   Plugin Name: Admin Init Priority 9
   */
   
   if ( ! defined( 'ABSPATH' ) ) {
   	exit;
   }
   
   add_action( 'admin_init', static function () {
   	global $wpdb;
   
   	$sql = 'SELECT COUNT(*) FROM nonexistent_table';
   	$count = $wpdb->get_var($sql);
   	if ( $count > 0 ) {
   		wp_die( 'It looks like this table actually exists' );
   	}
   }, 9 );

   This plugin is performing a database query that generates an error. It doesn't have anything to do with updates, but it runs in the admin_init action with priority 9, meaning it will run just before the check for updates in the admin section.

3. Apply this PR. Make sure it's the latest version with the last_error check.

4. Using WP-CLI, clear the update_plugins transient:

   wp transient delete --network update_plugins
   

   This will force an update check to occur the next time you visit an admin page.

5. Now visit any page in the admin section. This should generate a warning message: wp_update_plugins(): The result of the plugin update check could not be stored: Table 'wordpress.nonexistent_table' doesn't exist

   It's detecting an error, but the error doesn't really have anything to do with plugin updates.

I can think of a couple of ways that might be used to avoid this:

1. Use the wp_using_ext_object_cache() function before checking last_error:

   	if ( ! wp_using_ext_object_cache() && ! empty( $GLOBALS['wpdb']->last_error ) ) {
   		wp_trigger_error( ... );
   	}

2. Set last_error to the empty string first, before calling set_site_transient():

   	$GLOBALS['wpdb']->last_error = '';
   	set_site_transient( ... );
   	if ( ! empty( $GLOBALS['wpdb']->last_error ) ) {
   		wp_trigger_error( ... );
   	}

Good catch, you're right. $wpdb->last_error only reflects the transient write when the transient actually goes to the database. With an external object cache, set_site_transient() never runs a query, so last_error can be left over from something earlier in the request, exactly like your admin_init priority-9 example, and get misattributed to the update check.

Pushed fa6d86f to guard all three checks with wp_using_ext_object_cache(), so the last_error check only runs when the write is database-backed. When an object cache is in use there's nothing for last_error to tell us about transient storage anyway, so skipping it there loses nothing. The existing tests already skip themselves when an object cache is active, so they still cover the database path.

This does not look like a good solution. set_site_transient() needs a mechanism to signal a failure, such as an exception.

set_site_transient() needs a mechanism to signal a failure, such as an exception.

Yes, currently set_site_transient() has no way of signaling an error, because it calls update_option() and that has no way of signaling an error. (That is issue #41099.)

That's fair, and it's the real gap underneath this: set_site_transient() → update_option() has no way to signal a write failure (#41099), so the last_error check here is explicitly a workaround for that, scoped to the three update-check paths and guarded to only fire when transients are actually DB-backed.

I framed this as a narrow, interim fix for #64550 — so the update check stops reporting success after a write that didn't land — rather than a general solution to transient error-signaling. The root-cause storage fix is #13282; this was meant to sit alongside it as detection.

That said, if the preference is to hold this until update_option()/set_site_transient() can report failures properly (#41099), that's completely reasonable — I'm happy to pare it back or close it in favor of that direction. Whatever you and the maintainers think is the right path here.