UPDATE `wp_options` SET `option_value` ... WHERE `option_name` = 'fs_accounts' absolutely demolishes database on busy site

[archon810]

Actual Behavior:

• What is the issue? (*) I've been using WP Security Audit Log which uses Freemius for premium upgrades for a number of months. Today, I decided to upgrade to premium. The upgrade process took down our site (it's a busy one with millions of monthly PVs). This query was listed over and over in the db, hundreds of times, clogging up every connection. This is extremely poor coding, guys.

UPDATE `wp_options` SET `option_value` = <SNIP> WHERE `option_name` = 'fs_accounts'

I managed to recover from this, then installed the premium version of the plugin and attempted to activate it. Same thing. This time, I had to move the plugin physically on the disk and restart the db so that WP deactivates it. Insanity.

Take a look:

• What is the expected behavior? The query isn't repeatedly called, bringing down the database and the site.

Versions: (*)

• Freemius SDK Version: 2.2.2
• WordPress Version: 5.0.2
• PHP Version: 7.2

Plugin / Theme: (*)

• Name: WP Security Audit Log (regular and premium)
• Slug: wp-security-audit-log-premium
• Freemius ID: unable to find

Additional Information:

• Browser Type: (*) Chrome
• Browser Version: (*) 71
• OS: (*) Windows
• Stack Traces:

---

Note: (*) indicates required information. Without this information, your issue may be auto-closed.

You can find your Freemius SDK version at /freemius/start.php

You can find your Freemius product ID in the Freemius dashboard: SETTINGS -> INTEGRATION.

Do not modify the titles or questions. Simply add your responses to the ends of the questions. Add more lines if needed.

[archon810]

Upon the 3rd time trying this dance, I managed to get the premium plugin to activate without bringing the site down.

This issue should definitely still be fixed, especially since the plugin says it periodically pings freemius, which I'm afraid uses the same logic that causes that crazy query to start mass-executing, thus it may happen again at an unexpected point in the future when I may be away and unable to deal with the issue.

[archon810]

A similar issue was closed without a resolution https://github.com/Freemius/wordpress-sdk/issues/260.

[archon810]

In case it's relevant, I'll add that I noticed we're using another plugin that uses Freemius: https://wordpress.org/plugins/post-snippets/ (version 3.0.5).

The reason I bring that up is I noticed some Freemius-related notices today so maybe they're not playing well together, or they're unrelated. I'm not using a premium version of post-snippets.

For example: https://sentry.io/share/issue/a4a168fe4fdd405192831ed91df305ed/ https://sentry.io/share/issue/95b9cfa1b75b44dba889cf9b525f5a1f/

[vovafeldman]

@archon810 thanks for the report. Do you have a test/staging environment so we can troubleshoot?

[archon810]

I do, but the problem is it doesn't get any traffic compared to production and isn't likely to exhibit this issue. The live traffic is what's exacerbating this issue (as is common for race condition bugs, for example).

[vovafeldman]

There are tools to simulate highv traffic load so as long as the environment is identical we should be able to reproduce it.

[archon810]

I understand, but simulating this properly and without affecting the production db will be quite tricky. Additionally, I won't be available to look at stuff for at least a good week due to the New Year celebrations.

Can you try to brainstorm some reasons for why this could be happening based on the code you have and the report? What happens to this query that it is seemingly executed by every visitor to the site for some time (what is that time?) rather than just the admin user one time? I think you should be able to figure it out based on that.

[vovafeldman]

I will update here once we have any news.