[duncantmiller]

Problem

In Rails apps using a multi-threaded server (e.g. Puma) for system tests with Capybara, verify_recaptcha intermittently skips the skip_verify_env bypass and makes real HTTP verification calls to Google's reCAPTCHA API. These calls fail (timeout or invalid token), causing forms to re-render as if reCAPTCHA verification failed — despite the app running in RAILS_ENV=test.

Root cause: Recaptcha::Configuration#default_env is set once at initialization:

@default_env = ENV['RAILS_ENV'] || ENV['RACK_ENV'] || (Rails.env if defined? Rails.env)

When the singleton initializes before RAILS_ENV is fully available in a multi-threaded context, default_env is nil. Then skip_env?(nil) evaluates:

configuration.skip_verify_env.include?(nil || nil)  # => false

...bypassing the test-mode skip entirely, even though Rails.env would correctly return "test" at call time.

This is also demonstrated by the gem's own test helper, which explicitly deletes RAILS_ENV and RACK_ENV (test/helper.rb lines 2–3), meaning default_env is nil throughout the test suite.

Fix

Fall back to Rails.env at call time if default_env is nil:

def self.skip_env?(env)
  resolved = env || configuration.default_env
  resolved ||= Rails.env.to_s if defined?(Rails.env)
  configuration.skip_verify_env.include?(resolved)
end

This ensures the skip check always reflects the current Rails environment, even if the configuration was initialized before RAILS_ENV was set.

Tests

Added four tests for Recaptcha.skip_env?:

• Returns true for an explicit env matching skip_verify_env
• Returns false for an explicit env not in skip_verify_env
• Returns false when both env argument and default_env are nil (existing behavior, correctly documented)
• Returns true when default_env is nil but Rails.env is in skip_verify_env (the bug this fixes)

All 160 tests pass. RuboCop reports no offenses.

[grosser]

I kinda hate it because env being setup correctly should not be the gems problem ... but seems like the easiest fix 🤦

[grosser]

5.21.2