Remove caching in HoneypotService::getProtectedForms preventing proper invalidation

Here is a patch that applies cleanly to 2.2.0

Leftover in HoneypotSettingsForm::submitForm...
MR updated, and here's the updated 2.2.0 patch

Leftover again...
MR updated, and updated 2.2.0 patch

Yes, looking at the logs, it's legacy code that was added in the D7 version of Honeypot in 2011 by #1264822: More forms to select for protections → . The port to D8 was made in 2014 by replacing variable_get() and cache_set() with their D8 equivalents.

There have been no substantive changes to this piece of code since then. It was moved unchanged into a service and then a long-standing typing error (returning null instead of an array) was discovered and fixed because testing was failing with the service in the issue you mentioned.

I never understood why this double-caching method was implemented - there are no comments in the code. But I have left that section of code alone because up until now there have been no issues reported with it and I assumed there must have been a reason for adding the caching - I didn't want to trigger an old problem by removing the caching. Now that I've looked at the logs and read the original issue to figure out why this was done, I still don't see a reason why it was put there in the first place.

I have no problem with removing this legacy code.

Is the ??[] needed here $this->config->get('form_settings') ?? []? I believe form_settings is always an array.

Is the ??[] needed here $this->config->get('form_settings') ?? []? I believe form_settings is always an array.

Oh good point, indeed, otherwise it would have nullable: true in the config schema if I'm not mistaken.
MR updated.

Automatically closed - issue fixed for 2 weeks with no activity.