RecaptchaSettingsConfigSubscriber not found

Have you cleared all caches using drush cr after updating to the newest version?

RecaptchaSettingsConfigSubscriber is a new service introduced through 🐛 Ajax support / Use behaviors Fixed . Often enough, the old services.ymls are still cached and newly added services are not taken into account without flushed caches.

Another case could be, that you have a module installed, which alters your services yml.

@ryanrobinson_wlu please report this to miniorange so they can take a look. As you're the only one reporting this, I'll set this postponed until this is reproducible without miniorange on vanilla Drupal. Thank you!

PS: Please leave an update if it was fixed and how / where!

@Anybody I did report to miniorange. Their first response was "Based on my initial observation, it seems that the event subscribers of both modules are conflicting with each other."

But @grevil's comment gave me another idea. This error happened around the same time that we were doing some work on shifting to containerized deploys, starting with dev and staging. At one point in there we changed the name of the web Docker service being deployed, but the older ones were still there. There were a couple other minor things we fixed in between those early deployment tests with the old name and the newer tests with the new name, and sometimes we would see the issue in place again and sometimes not. I'm pretty sure what was happening is sometimes I was being served the old one instead of the new one, from before the bugs were fixed.

So I think there's a pretty good chance that what happened is that the earlier version of recaptcha without RecaptchaSettingsConfigSubscriber was deployed with the old Docker service name. Then the updated version of recaptcha came out and was deployed with the updated name. Sometimes when I was loading the site it served the old one, without RecaptchaSettingsConfigSubscriber but with the database expecting it to exist, creating a fatal error. That would explain why the problem, like the other reappearing bugs, were not entirely consistent, sometimes present and sometimes not. It would also explain why I could only replicate this problem on dev and staging servers, not on my local development environment.

I'll try to verify that theory and check back in - which might not be immediate since the new deploy process is not quite reliably done yet - but the timeline makes sense and the behaviour mostly makes sense. The only part that doesn't make sense is why uninstalling miniorange seemed to fix it, but maybe that was simply confusing luck that when I tried that I happened to always load the new Docker service without the error.

Update: I managed a minimal test - not everywhere that it was before, but enough I think - to feel fairly confident in the theory from the previous post. I did not get the error at all on about 20 page loads I tried and filled out the AJAX webform with a recaptcha on it a couple of times, submitting successfully.

Finding a project I'm on is encountering this.

Yes, its true a cache clear should resolve it. However procedure when modifying services.yml involves adding a new empty post_update function, which triggers a cache clear.

You can see core does this (moreso when you're not on a point-zero release, like 11.0), e.g user_post_update_sort_permissions

Would be good to add a new empty postupdate function, it obviously wouldnt be detrimental to existing sites.

Re-opening issue, as its a pretty easy thing to implement.