Skip Transaction Tracing for ActionController::RoutingError in a Rails Exception App

[silvermind]

HI guys,

I'm trying to prevent ActionController::RoutingError Transaction Events from being sent to Sentry. As regular pentest scans pollute our performance reports in sentry. The default config IGNORE_DEFAULT already skips the 'ActionController::RoutingError' Error Event, but the Transaction Event is still sent with status internal_error.

Using the Sampling Function seems a possible way to prevent TX recordings, but seems not to work for 404 & other routing errors as it's loaded quite early in the stack: https://docs.sentry.io/platforms/ruby/configuration/sampling/#setting-a-sampling-function

https://docs.sentry.io/platforms/ruby/configuration/sampling/#forcing-a-sampling-decision "Absolute decision passed to start_transaction" seems to be another way to control TX recording.

our Rails App has a configured Error Handler config.exceptions_app = ->(env) { ExceptionsController.action(:show).call(env) }

Is it possible to skip the Transaction Events recording from the Exception Controller somehow, while using the default rails instrumentation intact?

Any ideas & hints would be very welcomed. Alternative would be so filter our pentesters with UserAgent or IPs, would you suggest this route instead?

[sl0thentr0py]

Hi @silvermind, we added the whole rack env to sampling_context so you can use it in your traces_sampler. See an example below. Does that help?

https://github.com/getsentry/sentry-ruby/blob/c237974b185e51296542237cbca7f9c1ba1a7eb6/sentry-rails/spec/sentry/rails/tracing_spec.rb#L209-L217

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[silvermind]

worked :) thanks a lot.

would be nice to have the above sample with sampling_context[:env] added to the docs at: https://docs.sentry.io/platforms/ruby/configuration/sampling/

[aprescott]

I'm encountering this same issue. An application I work on has transactions from noisy requests to paths like /wp-login.php. I am trying to find some means of filtering them out.

Some gem info:

• rails 7.0.4.3
• sentry-ruby 5.8.0
• sentry-rails 5.8.0
• puma 5.6.5

I have tried config.excluded_exceptions += ["ActionController::RoutingError"], which doesn't seem to take effect.

When booting the Rails app and making a request for a path that doesn't exist (/does-not-exist), the transaction for the request is submitted to Sentry with a status of internal_error as part of a http.server operation. There is seemingly insufficient metadata to identify it as a 404.

Curiously, in investigating this, I noticed that in development (with SENTRY_DSN set) a 404'd request will submit a trace with not_found as a trace status, whereas in a deployed environment the 404'd path will submit a trace with internal_error. I'm not sure why the two environments differ in their status handling.

[ckdake]

Seeing this here as well, I have an open support ticket with Sentry to try and figure this out too.

[ckdake]

Support sent me to the idea to use a tag, and then filter on that tag, here is our workaround.

# app/controllers/application_controller.rb
  def route_not_found
    Sentry.set_tags("http.response_code": 404)
    render file: Rails.public_path.join("404.html"), status: :not_found, layout: false
  end

# config/initializers/sentry.rb
  config.before_send_transaction = lambda do |event, _hint|
    if event.tags.key?(:"http.response_code") && (event.tags[:"http.response_code"] == 404)
      nil
    else
      event
    end
  end

# config/routes.rb
match "*unmatched", to: "application#route_not_found", via: :all