Cache causing problems with setting/reading options in a plugin

  • Resolved scmsteve

    (@scmsteve)


    5 years, 1 month ago

    We have run into an issue with a plugin that was thinking it had to update its database even though it was already done, and it caused corruption. The plugin author fears this may affect other portions of the site.

    They say:
    Indeed, it was a caching issue that prevented WP options from being read correctly after an update call. Disabled the Litespeed cache plugin, and — issue gone. As a developer, you always expect that when you call add_option you’ll be able to use that value in the course of the same request.

    They were using get_optoin to get a value, then delete_option and add_option to make changes, and when the LiteSpeed cache was active it seems this was not working properly, their plugin was getting a stale value instead of the just-updated value.

    Is this something that can be fixed by some exclusions in the cache? It isn’t a particular page, it is the plugin code that is seeing this problem.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter scmsteve

    (@scmsteve)

    This may or not be related, but I was testing WooCommerce 3.9.1 update on our testsite with LiteSpeed Cache enabled, and after it did the update, a number of other plugins thought that the database had not been updated. Running WP-CLI ‘wp wc update’ triggered 75 updates going back from what looks like v2.00.

    This behavior is similar to what the other plugin was seeing where options were not set properly, although the cause is not guaranteed to be the same as I have no way to know exactly what happened here.

    If it matters, the LiteSpeed Cache plugin was disabled by the other developer during testing. When WooCommerce was updated, it was still disabled. I did not see those messages at that time. Then when I realized it was still disabled, I enabled it, and that is when these other messages appeared.

    • This reply was modified 5 years, 1 month ago by scmsteve.
    Thread Starter scmsteve

    (@scmsteve)

    Would it be burdensome or troublesome to add those hooks under the advanced options in LSCACHE?

    add_option
    delete_option

    That would ensure it is flushed when options are changed and they can’t get old data, right?

    Thread Starter scmsteve

    (@scmsteve)

    I wrote a small plugin that simply writes to the debug log the value retrieved from get_option, then does a delete_option, add_option, and prints a new get_option return value.

    If LSCache *object cache* feature is enabled, I get the strange behavior the other plugin author ran into. The second get_option returns the same value as the first even though there have been an intervening delete_option and add_option to reset it.

    If LSCache is running, but *object cache* is disabled, things work as expected.

    Even stranger, I hadn’t specifically meant to have object caching enabled on the test site, it came as the configuration when I copied from our live site. I do have a redis instance there, but I hadn’t set one up on the test site, so I don’t even know what it is object caching to if configured for redis but none exists…

    But this problem is happening on the live site and test site, so it seems something odd is happening in the base LSCache Object Cache feature.

    Is there a workaround?

    Hi @scmsteve thanks for the details report, this issue might be related to our recently found bug.

    Could you try to comment out rows 453 – 455 in plugin/litespeed-cache/inc/object.class.php:

    if ( ! $this->_can_cache() ) {
	return null ;
}

    and run the add option again to see does it back to normal?

    Thread Starter scmsteve

    (@scmsteve)

    Unfortunately that did not resolve the issue here. I have been away all day, sorry for the delay in getting back to you.

    Even more disturbing is that, as seen here, get_option at times fails to find the value at all. I don’t know if it was deleted and the add call failed because it thought it was still there or what exactly is going on. In fact, after doing the sequence of tests below I looked in the database and this option key is missing entirely, so it seems the delete worked but the add failed.

    But the value being stored is time() so it should change on every call, the “current value” is from the first get_option(), then we do a delete_option() and add_option() with a new time() value. So below when it reports the Updated, new value is, and it is the same as the “current value”, that means it is a cached value and not the new computed value that should be in there. With the object cache portion of LSCache disabled this works as expected and I have never seen the option missing from the database at the end of the get/delete/add/get sequence.

    [01-Feb-2020 03:09:38 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:09:39 UTC] SCM_DEBUG: Updated, new value is 1580526578
[01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Firing test, current value is 1580526578
[01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Updated, new value is 1580526578
[01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Updated, new value is 1580526653
[01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Firing test, current value is 1580526653
[01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Updated, new value is 1580526653
[01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Updated, new value is 1580526777
[01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Firing test, current value is 1580526777
[01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Updated, new value is 1580526777
[01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Firing test, current value is 1580526777
[01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Updated, new value is 1580526777
    • This reply was modified 5 years, 1 month ago by scmsteve.

    Thanks for the update @scmsteve, could you please join our Slack channel and find me(Stanley Cheung at Litespeed) or submit a ticket here for helping us to reproduce the bug, thanks.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Cache causing problems with setting/reading options in a plugin’ is closed to new replies.