Honor separately-configured user_name/password in AMQP connections

[vson-ic]

Context

Found while tracking down dchbx/edi_journal#194 — a consumer app was misusing connection_uri (a display-only, credential-free string) to open a manual Bunny connection. While tracing why the correct API (connection_params) is guaranteed to work, found a real gap underneath it.

The bug

BunnyConnectionProxy.connection_credentials_from_server only ever pulled credentials from userinfo embedded in the server's url (amqp://user:pass@host:port/vhost). But EventSource.configure's own DSL explicitly supports configuring credentials as separate fields:

config.servers do |server|
  server.amqp do |rabbitmq|
    rabbitmq.url       = ENV["RABBITMQ_URL_EVENT_SOURCE"]
    rabbitmq.user_name = ENV["RABBITMQ_USERNAME"]
    rabbitmq.password  = ENV["RABBITMQ_PASSWORD"]
  end
end

Whenever url was also present (which it almost always is), those separately-configured user_name/password fields were silently ignored, and the real connection fell back to ConnectDefaults' guest/guest unless url also happened to embed working credentials. That means connection_params (and the actual Bunny connection built from it) only worked correctly by coincidence in some environments, and would silently authenticate as guest/guest in others — no error raised, just a connection that may or may not be to the right account.

The fix

server[:user_name]/server[:password] now take precedence when both are present, falling back to URL-embedded credentials otherwise. Existing URL-embedded-credential behavior is unchanged — the existing "given a url with non-default credentials" spec still passes.

connection_uri is untouched — it stays a display-only, credential-free string (used for logging and as the connection registry key in ConnectionManager), so nothing about what gets logged changes, and there's no risk of leaking credentials into logs.

Test plan

• Added a spec covering separate user_name/password fields with a credential-free url.
• Verified in isolation (all three cases: URL-embedded credentials, separate fields, and no credentials/defaults) since this repo's full test suite doesn't currently install cleanly against Ruby 3.4 (unrelated nio4r/Rails 6.1 native-extension issue on this Gemfile.lock).
• Run full spec suite in CI / an environment matching the pinned Ruby version before merge.

🤖 Generated with Claude Code