update_option() failing

  • Resolved Oliver Campion

    (@domainsupport)


    1 year, 1 month ago

    Hi,

    Whist working to diagnose an un-related CRON issue, we have noticed that quite a lot of Wordfence originating update_option() commands are failing. We found this by adding some error_log() and $wpdb->print_error() to /wp-includes/option.php.

    Here are some examples from debug.log …

    [09-Mar-2023 23:41:27 UTC] Failed to save option "wordfence_syncAttackDataAttempts" to the wp_options table with value: 1 (integer) and old value: 0 (string) and error:
[09-Mar-2023 23:41:27 UTC] WordPress database error for query UPDATE wp_options SET option_value = '1', autoload = 'no' WHERE option_name = 'wordfence_syncAttackDataAttempts' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::veryFirstAction, update_site_option, update_network_option, update_option
[09-Mar-2023 23:43:18 UTC] Failed to save option "wordfence_syncAttackDataAttempts" to the wp_options table with value: 1 (integer) and old value: 0 (string) and error:
[09-Mar-2023 23:43:18 UTC] WordPress database error for query UPDATE wp_options SET option_value = '1', autoload = 'no' WHERE option_name = 'wordfence_syncAttackDataAttempts' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::veryFirstAction, update_site_option, update_network_option, update_option
[10-Mar-2023 06:15:09 UTC] Failed to save option "wordfence_syncAttackDataAttempts" to the wp_options table with value: 2 (integer) and old value: 1 (string) and error:
[10-Mar-2023 06:15:09 UTC] WordPress database error for query UPDATE wp_options SET option_value = '2', autoload = 'no' WHERE option_name = 'wordfence_syncAttackDataAttempts' made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::veryFirstAction, update_site_option, update_network_option, update_option
[10-Mar-2023 06:15:45 UTC] Failed to save option "wordfence_syncAttackDataAttempts" to the wp_options table with value: 1 (integer) and old value: 0 (string) and error:
[10-Mar-2023 06:15:45 UTC] WordPress database error for query UPDATE wp_options SET option_value = '1', autoload = 'no' WHERE option_name = 'wordfence_syncAttackDataAttempts' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::veryFirstAction, update_site_option, update_network_option, update_option

    Instead of the number of rows updated, false is returned by your update_option() request but no error is in $wpdb->print_error().

    Can you think of any reason why this might be happening? Could it be possible that one of these is true …

    1. Whilst update_option() is fired, the option has been deleted by another concurrent page load so the UPDATE query has no option to update?
    2. Whilst update_option() is fired, the option has already been updated by another concurrent page load so the UPDATE query has nothing to update?

    The site in question often receives Wordfence notifications like this (and the date / time of the attack matches the entries in debug.log) …

    The Wordfence Web Application Firewall has blocked 483 attacks over the last 10 minutes. Below is a sample of these recent attacks:March 10, 2023 6:13am 146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents
    March 10, 2023 6:13am  146.190.86.194 (Singapore)     Blocked for Known malicious User-Agents

    Your thoughts would be appreciated.

    Thank you,

    Oliver

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support wfpeter

    (@wfpeter)

    1 year, 1 month ago

    Hi @domainsupport, thanks for reaching out to us about this.

    We do think it looks like it could be a race condition, and related to the possible issue in update_option() itself – that also looks like a race condition.

    As these are fairly common to see in WordPress, we often suppress them with $wpdb->suppress_errors() when a specific hit on the database has already been performed, as we can’t prevent the errors ourselves. If this is only happening on wordfence_syncAttackDataAttempts while we try to increment the counter, it shouldn’t have a significant effect on the plugin.

    Many thanks,
    Peter.

    Thread Starter Oliver Campion

    (@domainsupport)

    1 year, 1 month ago

    Hi Peter,

    Thank you very much for coming back to me about this.

    OK, so you think it’s a race condition too. Interesting.

    Even more interesting that you’re aware of the cron could_not_set issue that I raised. However I have already ruled out a race condition causing that because that issue still presents itself even when cron is being fired by the system rather than the default page requests. So that issue is unrelated in my opinion.

    Do you think the race condition with update_option() (if that’s what it is) could be avoided somehow? It would be good to get this issue resolved, maybe at the same time as this issue … ?

    Looking on trac, do you think this could be the same issue … ?

    Thanks again,

    Oliver

    Thread Starter Oliver Campion

    (@domainsupport)

    1 year ago

    Hi @wfpeter,

    Just coming back to this because it’s almost certainly a race condition as you suspect.

    The issue only affects options wordfence_syncAttackDataAttempts and auto_updater.lock.

    The former is your option, the latter is a core option specifically designed to prevent this type of race condition!

    So I’m going to mark this as “resolved” because I don’t think anything can be done about it.

    Oliver

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘update_option() failing’ is closed to new replies.