match_message ambiguity with custom error objects in RSpec request specs

Answer first

p>No. RSpec does not have a built-in global match_message matcher. The behavior you see in request specs comes from a custom matcher or a gem extension defined in your project. Because the matcher is custom, whether it requires exact string match, substring inclusion, or pattern matching is determined by its implementation, not by RSpec core.

Confirmed facts:

• RSpec core provides string matchers like eq for exact equality, include for substring containment, and match for regex. There is no core match_message.
• Rails error objects typically respond to #message.. message matcher will call that method and compare the returned value.

Likely explanation for the ambiguity you describe:

Your match_message is probably a thin wrapper that extracts error.message and then delegates to one of the core string matchers. If it delegates to eq, tests will be fragile to I18n, punctuation, and dynamic content. If it delegates to include or match, unrelated messages containing the same substring can pass.

Devise and CanCanCan raise different error types, but both expose a human-readable #message. Relying on the human-readable string to differentiate credential-expired vs permission-denied is unreliable across locales and message rewrites.

Steps needed for this case

1. Inspect the spec/support directory or rails_helper.rb to locate the definition of the match_message matcher.
2. Run a test case with a known failing string to determine if the matcher uses ==, include?, or =~.
3. Create a minimal reproduction case with a custom error class to observe how the matcher handles different #message return values.

A typical custom definition looks like this:

RSpec::Matchers.define :match_message do |expected|
  match do |actual|
    actual.message == expected   # exact match
    # or actual.message.include?(expected) # substring
    # or actual.message =~ expected       # pattern
  end
end

If the matcher uses exact equality, dynamic content or localization will cause false negatives. If it uses substring/regex, different error signals can produce false positives.

Reliable differentiation

Avoid differentiate credential-expired vs permission-denied by free-form message. Prefer stable identifiers:

• Match on error class: expect { }.to raise_error(Devise::ExpiredTokenError)
• Match on a dedicated error code or i18n key, not the rendered string.
• If you must check a message, use a regex anchored to a unique token and pin the locale in the spec.

One missing detail that changes the recommendation: the source code of your match_message matcher. Provide the definition from spec/support or rails_helper.rb and I can confirm whether it uses eq, include?, or =~ and suggest a safe replacement.