Errors caught by rescue_from are still reported in New Relic

[amoslanka]

I use the Grape::Middleware::Error rescue_from method to rescue errors such as validation errors and "record not found" errors. These exceptions are returned as valid json responses using appropriate statuses such as 422 or 404. They're expected responses, not the type of errors I would expect to need to monitor using New Relic.

The middleware stack as it is currently built is in the following order:

• Rack::Head
• Grape::Middleware::Error
• Grape::Middleware::Formatter
• NewRelic::Agent::Instrumentation::Grape

Since the New Relic instrumentation is at the end of the stack, its reporting the expected errors to New Relic and then reraising the errors which are later rescued and dealt with. The reported errors represent a false positive, they say the app failed when really it didn't. My impression is that the instrumentation should allow the Error middleware to execute first, and report any errors that make it past that middleware in the stack.

In a newrelic-grape fork, I've been unable to find a way to reorder the middleware in the build_middleware method. I'm assuming that a more appropriate order for the middleware would be:

• Rack::Head
• NewRelic::Agent::Instrumentation::Grape
• Grape::Middleware::Error
• Grape::Middleware::Formatter

Am I assuming correctly that this should be the order of middleware and am I understanding the nesting and order of execution of Rack Middleware? If not then I am dealing with some other reason as to why the instrumentation is executed in the stack before the Error rescue.

[flyerhzm]

I didn't dive into the source code, but I remember newrelic allow to set unreported errors, you probably need to hack rescue_from method, remember those errors and tell newrelic not to report those errors.

I will do it later.

[flyerhzm]

I have changed the order of newrelic grape middleware, let it use before Grape::Middleware::Error, could you try and let me know if it works?

[amoslanka]

Everything looks correct from the perspective of my staging environment. I think this likely did the trick, though of course over time my production environment will provide more information. Thanks!