How to suppress NoRouteError in Phoenix 1.7.2 and Bandit?

Ever since I upgrade to Phoenix 1.7.2 and Bandit, my log file is polluted with junk such as:

14:38:32.113 request_id=F1pur8zunbgsR1kAAoIR [error] GenServer #PID<0.9364.14> terminating
** (Phoenix.Router.NoRouteError) no route found for GET /sitemap.xml (RoastidiousWeb.Router)
...

I don’t want to make a catch-all route just to do 404, and I don’t remember seeing this back when I was using cowboy. Is there a way to config the stack to suppress logging for NoRouteError only?

1 Like

Yep, I agree this is sub-par. Fix is coming to Bandit in the next few hours to quell this logging.

5 Likes

Thanks for the quick response. I did some digging, it appears that:

  • Phoenix always raise for 404
  • Cowboy suppresses logging from all exceptions raised within a http handler
  • Bandit doesn’t suppress logging

I’d like to see the Bandit’s behavior to be configurable. Since 404 is a fact of life on the internet, and some developer may want to see a stack trace for 500s in production, can we have a configuration parameter for the minimal HTTP status code for stack trace logging?

I got most of the way through exactly what you suggested, but then realized that Phoenix isn’t actually supposed to be raising NoRouteError errors externally (see phoenix/render_errors.ex at main · phoenixframework/phoenix · GitHub)

This looks like a loooooooongstanding error in Phoenix that’s been silently canceled out by Cowboy’s silent error handling.

I’m working up the last bits of a PR for Phoenix to correct this, at which point we’ll end up with a better end result:

  • Phoenix renders NoRouteError errors and doesn’t raise them further
  • Phoenix renders all other errors and raises them further
  • Bandit logs loudly on all errors it receives
  • Cowboy doesn’t log errors it receives

This will end up with Bandit continuing to log all non NoRouteError errors loudly, which is what we want in general. NoRouteErrors will be silenced within Phoenix, which is really the correct place to be expressing this logic.

Expect Phoenix PR by end of day.

7 Likes

Follow along at Do not re-raise on NoRouteError by mtrudel · Pull Request #5445 · phoenixframework/phoenix · GitHub!

3 Likes

To be clear, the Phoenix changes above only affect 404’s sourced from a NoRouteError error (that is, a request such as /bogus_route). 404’s sourced from a secondary issue such as an Ecto record not found error (ie: /users/123 where 123 is an invalid user id) are not covered here. The expectation is that in those cases you maintain your own error handling in ErrorHTML or elsewhere (put another way, such errors never ought to have surfaced out of Phoenix anyway).

3 Likes

For posterity, this is merged and released as part of Phoenix 1.7.3

4 Likes