When ActionDispatch::ShowExceptions captures an error, it renders the appropriate error page and then sets the correct exit status. To do this, it reuses the rack env (wrapped in a Request), and resets the path_info to /#{status} and runs that request with an exceptions_app. This may[1] result in the controller and action being overriden, since the exceptions_app will parse the path info and route to a different controller/action. This results in the wrong labels being added to the prometheus metrics.
[1] At least, when an exception app is configured with config.exceptions_app = routes.
We have worked around this locally by re-parsing the path when setting the labels:
def default_labels(env, result)
labels = super
if labels[:controller] == "errors"
params = begin
Rails.application.routes.recognize_path(env["REQUEST_PATH"])
rescue ActionController::RoutingError
nil # Si no podemos parsear no reemplazamos nomas
end
if params
labels[:controller] = params[:controller]
labels[:action] = params[:action]
end
end
labels
end
I don't know how to cleanly fix this. This only works for us because we know the "errors" controller is only used for error routing.
When
ActionDispatch::ShowExceptionscaptures an error, it renders the appropriate error page and then sets the correct exit status. To do this, it reuses the rack env (wrapped in a Request), and resets thepath_infoto/#{status}and runs that request with anexceptions_app. This may[1] result in the controller and action being overriden, since theexceptions_appwill parse the path info and route to a different controller/action. This results in the wrong labels being added to the prometheus metrics.[1] At least, when an exception app is configured with
config.exceptions_app = routes.We have worked around this locally by re-parsing the path when setting the labels:
I don't know how to cleanly fix this. This only works for us because we know the "errors" controller is only used for error routing.