The idea is to allow us to set custom status code for when a exception occurs during a transaction, something like
Sentry.init do |config|
config.exception_status_code = ->(exception) do
case exception
when ActiveRecord::RecordNotFound, ActionController::RoutingError
404
else
500
end
end
end
Why do you think it's beneficial to most of the users
Sentry assumes status code 500 (internal error) for all of the exceptions during transactions. The problem is that in a production environment, by default Rails will raise ActionController::RoutingError whenever somebody tries to access a non-existing page, which will result in "internal error" transactions.
This feature allows the user to map different exceptions to different status codes, so they can ignore that without having to change the default Rails behavior.
Possible implementation
In the Sentry::Rack::CaptureExceptions we can replace the hardcoded 500 status code from the rescue Exception with a configurable lambda that returns the desired status code for the specific exception.
Another possibility, is to bake this rule into Sentry (404 for routing errors), but I think that would be a shift in the current behavior which might not be ideal
Describe the idea
The idea is to allow us to set custom status code for when a exception occurs during a transaction, something like
Why do you think it's beneficial to most of the users
Sentry assumes status code 500 (internal error) for all of the exceptions during transactions. The problem is that in a production environment, by default Rails will raise
ActionController::RoutingError
whenever somebody tries to access a non-existing page, which will result in "internal error" transactions.This feature allows the user to map different exceptions to different status codes, so they can ignore that without having to change the default Rails behavior.
Possible implementation
In the
Sentry::Rack::CaptureExceptions
we can replace the hardcoded 500 status code from therescue Exception
with a configurable lambda that returns the desired status code for the specific exception.Another possibility, is to bake this rule into Sentry (404 for routing errors), but I think that would be a shift in the current behavior which might not be ideal