I recently upgraded an application to Rails 6, and after seeing
ActionDispatch::DebugExceptions interceptors I thought that I could get rid of a monkey patch, but it wasn’t possible in the end. That’s what drove me to open this issue.
This was somewhat already discussed in Allow DebugExceptions interceptors to abort default backtrace error log by wjordan · Pull Request #33609 · rails/rails · GitHub, and it was pointed out that the interceptors are not the right tool for the job.
It was also mentioned that it’s possible to silence specific exceptions by using the
silent_exceptions config option.
Currently, the method
ActionDispatch::DebugExceptions logs out a multiple line message, that may look good in a terminal, but in a logging management system - e.g. Datadog - looks like the following:
This adds unnecessary noise since there are four different lines for the same exception. The only way to get rid of this behavior right now is to monkey patch
ActionDispatch::DebugExceptions and override the
What I want to get is a good instrumentation by using structured logging for my application. One of the main goals is to have “one log entry for each unit of work” or “one log entry for each request”.
I’m opening this issue to see if there are any thoughts on how a custom log format could be provided to
ActionDispatch::DebugExceptions. I understand that aborting the interceptors is not the answer, and I think silencing the exceptions also isn’t.
In my situation - and possibly others in Allow DebugExceptions interceptors to abort default backtrace error log by wjordan · Pull Request #33609 · rails/rails · GitHub - we do want the exceptions to be reported (or logged in this case) but we would like to format the log message in a way that makes sense for the application.
Right now, tools such as GitHub - roidrage/lograge: An attempt to tame Rails' default policy to log everything. are able to provide a good log formatting option, but they fall off short for this situation. Maybe there is a better way of developing such tools (I don’t have much knowledge about it), and if that’s the case, let me know.
Logging out a single line would probably be enough for my use case, but I have the impression that the exception logging in this module is not something intended for production logging like we have been using it for. So I’m curious to hear what the maintainers think about this.