Updating settings requires a cache clear

In the meantime, you can clear just the version block settings via drush :

drush @yoursite.prod php:eval "\$item = \Drupal::cache()->get('bot_blocker.min_versions'); var_dump(\$item ? \$item->data : 'Not found');"

Clearing the substrings
drush @yoursite.prod php:eval "\$item = \Drupal::cache()->get('bot_blocker.banned_substrings'); var_dump(\$item ? \$item->data : 'Not found');"

Thanks for fixing this, I have seen it in other modules as well. It makes you wonder if saving a settings form should be default rebuild caches, except if it's disabled in the code. On the other hand, it might makes things slow down -- it's a balance :)

Well, in this case, I am explicitly caching these settings in an extra layer, which may be unnecessary, I was trying to be certain that we minimize any database reads while dealing with potentially hundreds of bot requests a second. So We just need to explicitly clear that cache item, or update it with new values on form submission.

It was just something I noticed, because I was dealing with a surge in bots, all using Chrome 134. It seems like a bit of a shift in the behavior we've been seeing in this activity over the prior months.

Interestingly, I have also seen an increase in traffic recently, rising the last 7-10 days and hitting a maximum yesterday and today, with Load Average hitting 97 on the server! Interestingly, a new trend is emerging: All visits come from a varied range of IP's, so it's impossible to block them by IP. I thought it was a DDOS, because it certainly looks like a DDOS .... I see no pattern in Chrome versions. Could it be that a new generation of multi-IP bots have been released?

CPU and traffic last 30 days.