get_transient() will always return the value of a broken transient

[deconf]

In 4.2:

1. Create the transient
2. Delete its timeout
3. Call get_transient()

FALSE is returned

In 4.3:

1. Create the transient
2. Delete its timeout
3. Call get_transient()

the value of a broken transient gets returned indefinitely

See: [33110] and #30380

Note that a transient can get broken for a number of reasons and not necessary through intentionally deleting its timeout.

[deconf]

Revert to old check

[deconf]

cleanup

[johnbillion]

Let's get some tests in here to demonstrate the behaviour.

[johnbillion]

Replying to deconf:

Note that a transient can get broken for a number of reasons and not necessary through intentionally deleting its timeout.

While this is technically true, is there a way for a transient timeout to get deleted other than by removing its entry in the wp_options table via a database query? I don't believe it's possible via the API.

[deconf]

No, it's not, that's why I didn't worried too much about this ​post. The production tests proved me I'm wrong, big time, after some bad reviews (well that happens from time to time) and ​this topic.

I can't tell for sure what's the cause of those timeouts getting deleted, but IMHO an invalid/broken transient shouldn't lead to a valid response.

[ocean90]

No revert please. get_site_transient() is doing the same. If we want to handle broken transients we could set $value to false if $timeout is false.

I can't tell for sure what's the cause of those timeouts getting deleted,

That's the real issue and should be investigated.

[deconf]

handles broken transients

[deconf]

code format fix

[deconf]

Looks like at least one backup plugin is deleting the timeouts (when object cache is not used). If it's actually trying to clean-up the database prior to a backup, I don't understand why will it only delete the timeouts, but whatever.

[Otto42]

We reported this bug to the plugin author and explained why using delete_transient() is better all around.

However, what's the reasoning behind the original change in the first place? Simply to avoid an extra couple DB queries? I mean, I get that, but does it fix some other deeper bug I'm not seeing?

Seems like a side-effect behavior change was made. It's entirely possible that some other plugin code relied on that side-effect without necessarily knowing it as well.