WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 20 months ago

#33561 new defect (bug)

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

Reported by: deconf Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.3
Component: Options, Meta APIs Keywords: needs-unit-tests has-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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.

Attachments (4)

option.php.patch (557 bytes) - added by deconf 2 years ago.
Revert to old check
option.php.2.patch (597 bytes) - added by deconf 2 years ago.
cleanup
option.php.3.patch (1.0 KB) - added by deconf 2 years ago.
handles broken transients
option.php.4.patch (1.0 KB) - added by deconf 2 years ago.
code format fix

Download all attachments as: .zip

Change History (13)

@deconf
2 years ago

Revert to old check

@deconf
2 years ago

cleanup

#1 @SergeyBiryukov
2 years ago

  • Description modified (diff)

#2 @johnbillion
2 years ago

  • Keywords needs-unit-tests has-patch added

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

#3 in reply to: ↑ description @johnbillion
2 years ago

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.

#4 @deconf
2 years ago

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.

Last edited 2 years ago by deconf (previous) (diff)

#5 @ocean90
2 years ago

  • Keywords has-patch removed

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
2 years ago

handles broken transients

@deconf
2 years ago

code format fix

#6 @deconf
2 years ago

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.

#7 @deconf
2 years ago

  • Keywords has-patch added

#8 @Otto42
2 years ago

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.

This ticket was mentioned in Slack in #polyglots by deconf. View the logs.


20 months ago

Note: See TracTickets for help on using tickets.