Options, Meta APIs: Do not store a transient value without its timeout. - #14340

Trac ticket: https://core.trac.wordpress.org/ticket/52345

Refreshes the approach from #910 by @menno-ll (now conflicting with trunk), following @peterwilsoncc's suggestion in comment:5 on the ticket.

Summary

When set_transient() creates a transient with an expiration, it writes two rows: _transient_timeout_{name} and _transient_{name}. On the "add" paths the result of writing the timeout row was ignored, so if the database rejected that INSERT the value was still stored. With no timeout row, get_transient() returns the value forever. set_site_transient() has the same pattern. sukhendu2002 confirmed the behaviour on trunk in #44977 (comment:5).

Fix

On the add paths, the value is now only stored when the timeout row was written or already exists:

$result = add_option( $transient_timeout, time() + $expiration, '', false )
	|| '' === $wpdb->last_error
	|| false !== get_option( $transient_timeout );

add_option() returning false is not enough on its own to mean "failed":

• Concurrent requests. It uses INSERT … ON DUPLICATE KEY UPDATE. If another request wrote the same timeout in the same second, MySQL reports 0 changed rows and add_option() returns false. The cache primed at the start of set_transient() still says the row is missing, so only the database error tells a real failure apart. wpdb::query() resets last_error before every query.
• Orphaned timeout rows, for example when only the value row was deleted. add_option() returns false without querying, and these keep today's behaviour through the get_option() check.

The same rule applies to the branch that adds an expiration to an existing transient without a timeout, and to set_site_transient().

The update paths, where a timeout row already exists, are unchanged. A failed update there still leaves an expiry in place. It also avoids a trap in #910: update_option() returns false when the value is unchanged, so treating that as a failure drops a second set_transient() with the same expiry in the same second.

Testing

New tests (@ticket 52345) in Tests_Option_Transient and Tests_Option_SiteTransient. The database failure is simulated by pointing only the timeout INSERT at a missing table, so wpdb reports a real error, and a concurrent write by replaying the same INSERT from the query filter.

The 3 failure cases fail on trunk; all 9 pass with this change, on single site and multisite:

./vendor/bin/phpunit --group 52345                                   OK (9 tests, 24 assertions)
./vendor/bin/phpunit -c tests/phpunit/multisite.xml --group 52345    OK (9 tests, 24 assertions)
./vendor/bin/phpunit --group option                                  Tests: 451, Assertions: 1118, Warnings: 1, Skipped: 3
./vendor/bin/phpunit -c tests/phpunit/multisite.xml --group option   Tests: 486, Assertions: 1232, Warnings: 1, Skipped: 3

The one warning is an existing PHPUnit 10 deprecation notice in Tests_Option_wpUserSettings.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Tracing the transient write paths, writing the fix and tests, and reviewing it for regressions (two review passes found the concurrent-request case, which is now covered by tests). All changes were reviewed by me.

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.