Add ClientStub, setup/client_for API, and Railtie

[rosa]

Summary

• Rspamd::ClientStub — Null-object client that returns ham for check and no-ops for training methods. Used when rspamd is disabled (dev/test environments).
• Rspamd.setup(config) / Rspamd.client_for(:name) — Thread-safe client management with config loading. Returns cached Rspamd::Client instances (or ClientStub when disabled).
• Rspamd::Railtie — Auto-calls Rspamd.setup after Rails init if config/rspamd.yml exists.

Usage

# config/rspamd.yml
production:
  enabled: true
  inbound:
    host: rspamd-in.example.com
    port: 11334
    password: secret
  outbound:
    host: rspamd-out.example.com
    port: 11334
    password: secret

# Railtie auto-configures, then:
Rspamd.client_for(:inbound).check(message)
Rspamd.client_for(:outbound).spam!(message)

Test plan

• ClientStub tests (7 tests)
• Setup/client_for tests (8 tests)
• All existing tests pass (31 runs, 57 assertions)
• Integrated and tested in HEY (haystack) — 44 rspamd-related tests pass

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds Rails integration helpers for rspamd-ruby so Rails apps can auto-configure and obtain per-purpose clients, with a null-object stub when disabled.

Changes:

• Introduces Rspamd::ClientStub (null client) and Rspamd::Rails (client/config management) plus a Rspamd::Railtie for auto-setup.
• Adds activesupport runtime dependency to support deep_symbolize_keys.
• Adds test coverage for the new stub and Rails helper.

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
lib/rspamd/client_stub.rb	Adds a null-object client for disabled/dev/test usage.
lib/rspamd/rails.rb	Adds Rails-facing setup + client lookup/caching.
lib/rspamd/railtie.rb	Auto-initializes configuration from config/rspamd.yml in Rails.
lib/rspamd-ruby.rb	Wires new files into the gem entrypoint.
rspamd-ruby.gemspec	Adds activesupport as a runtime dependency.
test/client_stub_test.rb	Tests expected stub behaviors.
test/rails_test.rb	Tests Rails helper setup, caching, reset, and stub fallback.
Gemfile.lock	Updates lockfile to include new dependency and other dependency changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

client_for caches clients with @clients[name] ||= ... and setup/reset! mutate @clients/@config without any synchronization. This is not thread-safe under multi-threaded Rails servers (can build multiple clients, or race with reset and raise due to nil config). Consider guarding config/client access with a Mutex (or using a thread-safe map) to ensure only one client is built per name and reads/writes are consistent.

Suggested change

	@config = config.deep_symbolize_keys
	@clients = {}
	end
	def client_for(name)
	return ClientStub.new unless enabled?
	@clients[name] ||= build_client(name)
	end
	def reset!
	@config = nil
	@clients = {}
	end
	private
	def enabled?
	@config&.dig(:enabled)
	mutex.synchronize do
	@config = config.deep_symbolize_keys
	@clients = {}
	end
	end
	def client_for(name)
	mutex.synchronize do
	return ClientStub.new unless @config&.dig(:enabled)
	@clients ||= {}
	@clients[name] ||= build_client(name)
	end
	end
	def reset!
	mutex.synchronize do
	@config = nil
	@clients = {}
	end
	end
	private
	def mutex
	@mutex ||= Mutex.new
	end
	def enabled?
	mutex.synchronize do
	@config&.dig(:enabled)
	end

[Copilot]

HAM_RESULT is a single shared Check::Result instance returned by check. While the result object is frozen, the nested data hash/arrays (and e.g. symbols) remain mutable, so any consumer mutation will leak across calls/threads. Consider returning a fresh Check::Result per call, or deep-freezing/duplicating the nested data before exposing it.

[Copilot]

test_accepts_string_keys appears redundant with test_returns_client_when_enabled (both already pass string keys to setup). If the intent is to verify symbol-vs-string handling, consider adjusting one test to pass symbol keys (or remove this test if it's not adding distinct coverage).

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

rspamd/rails is unconditionally required here, but it in turn does require "active_support/core_ext/hash/keys". This means every user of this gem (including non-Rails projects) is forced to install and load activesupport as a runtime dependency.

The Railtie is already conditionally loaded (if defined?(::Rails::Railtie)), but rspamd/rails should receive the same treatment — either guard it similarly (e.g., require "rspamd/rails" if defined?(::ActiveSupport)) or move the require into the Railtie so it's only loaded in Rails apps.

Suggested change

	require "rspamd/rails"
	require "rspamd/rails" if defined?(::ActiveSupport)

[Copilot]

Adding activesupport as an unconditional runtime dependency is a heavy requirement for what is currently used only for deep_symbolize_keys in Rspamd::Rails. This forces all consumers of this gem (including non-Rails projects) to pull in activesupport and its transitive dependencies.

Consider either:

1. Making activesupport an optional dependency and only requiring it in the Rails-specific code path, or
2. Implementing the deep_symbolize_keys logic inline (it's a small recursive method) to avoid the dependency entirely for the core gem.

Suggested change

	s.add_dependency "activesupport", ">= 6.0"
	s.add_development_dependency "activesupport", ">= 6.0"