Too many checking_for_updates requests

[Streamlinelv]

Hi,

For the most part we see that update check requests are coming once or twice a day, but a couple of our customers are sending thousands of these requests each day. I'm attaching a screenshot.

Is this a known issue and if it is, are there any plans in resolving it? Or maybe there is something that we can do to limit it via our plugin?

We are suing Plugin Update Checker Library 5.4.

[YahnisElsts]

An old version had a bug that could cause excessive update requests, but that was fixed long ago. It should no longer happen with version 5.4. Could it be that the customers in question have a very old version of your plugin that is using a very old version of PUC?

Also, it looks like the screenshot did not upload properly.

Edit: You can control how often PUC checks for updates in multiple ways, but that will only help if the extra requests are not caused by a bug or an outdated PUC version. For example, you could use the check_now filter to abort update requests when some custom conditions are met.

$updateChecker->addFilter(
	'check_now',
	function ($shouldCheck, $lastCheckTimestamp, $checkPeriod) {
		if ( should_stop_this_request() ) {
			return false;
		}
		return $shouldCheck;
	},
	10,
	3
);

[Streamlinelv]

Thank you for your response. Updated my initial post with screenshot. Unfortunately this is not the case of outdated PUC version since the client uses our v10.1 plugin release which already includes 5.4 version of PUC.

[YahnisElsts]

Well, I'm not aware of any current bugs or conflicts that could cause this kind of issue.

Some other ideas, mostly not very plausible:

• External factors triggering requests
  • Do the customers use an automated or remote site management tool that might be checking for updates more often than normal?
  • Something silly like running wp plugin update --all in a cron job that triggers every minute?
  • Opening the "Dashboard -> Updates" or "Plugins -> Installed Plugins" pages very often? By default, PUC tries to emulate how plugin updates work in WP core, so it will check for updates more often on certain admin pages.
• Storage issues
  • Partially corrupted wp_options table fails to store update data so PUC keeps checking over and over?
  • Broken caching layer returns stale update data so PUC thinks it hasn't checked for updates in a long time?
  • Update details contain certain Unicode characters (e.g. emojis) that cannot be represented in older versions of the utf8 MySQL character set and the customer's site happens to use that outdated character set?

If you have access to the customer's site, some of the "storage issues" possibilities can be tested by using the Debug Bar plugin. The "PUC (your-slug)" section should show the last check timestamp. You can test if the timestamp changes after you check for updates (you'll need to refresh the page to refresh the debug info).

[DavidAnderson684]

@YahnisElsts If you have a moment, could you identify for me the commit that fixes the issue? Having seen it in my logs for years (but never found the cause because of the difficulty of accessing an end user site who has it), I'm very curious! (On my end I "resolved" it by using prepended PHP code to detect servers making such requests and firewall their requests).

[YahnisElsts]

Unfortunately, it was years ago and I no longer remember what the original issue was. I spent some time looking through the history (including from before PUC was migrated to GitHub) and found 5aee0d7b8b9ee7de992111551f3846ebcf591f6f where a Cron-related bug in another plugin apparently caused me a lot of trouble. However, I'm not sure if that's really the one.

[DavidAnderson684]

Thanks for looking!