I am now having this same error on my sites that have been working for many months. Should I create a new thread or do you just want to tag on here? I assume you can see the domains and IP addresses for all my sites as they are registered in The Hub.
I also found that Hummingbird does not play nice with Beaver Builder so I am leaving it disabled for now. I am hopeful that you guys will figure out how to make it more robust and release an update by the time I am ready to turn it back on. Until then, my site won't be a useful place to troubleshoot.
Transients are always used, it's just a question of which method. With memcached active they are not persisted in the database. In fact, this is one of the ways I was able to determine that WP still thought memcached was active even after it had been disabled. It turns out the SG SuperCacher plugin forces the setting and does not clear it even if disabled or the plugin deleted, and you can't clear it unless you first actually enable it, and then it will allow you to disable it again.
I am convinced the root of this problem lies in WP use of transients and interaction with the SiteGround Supercacher Memcached. Since I had previously simply disabled the plugin and used cPanel to disable the cache, I wondered if WP was still trying to use it. I re-enabled the plugin and sure enough it's config screen showed Memcached active even though it was disabled on the server. I could not disable it through the plugin until I re-enabled it through cPanel, at which point I could disable in the plugin and then disable again in cPanel. At that point cron jobs began processing again and immediately cleared the backlog.
I think we can safely conclude that the issue with cron jobs not processing is one for SiteGround so I will report it to them.
I don't know if this resolves the initial issue here of Defender getting stuck and processing the same files hundreds of times, but at this point let's close this ticket and I will open a new one if the problem occurs again.
WP default cron handling is queueing up crons but not running any. In the past I found this was because the check on line 88 of wp-cron.php fails because doing_cron_transient is empty...
My system scheduled cron job is running every 5 minutes and is consuming a single job each time before aborting because the check for _get_cron_lock() on line 120 returns an empty value for the doing_cron transient...
I am not sure when it stopped working... if it was when I disabled caching as mentioned above or when your guys were in the system (they left Debug Bar and Debug Bar Cron plugins behind... those were not installed when I went to bed last night...).