Open gilbsgilbs opened 7 years ago
Based upon the closed PR, it seems like this is a "wontfix" issue? If so I still don't see any documentation about ProcessorFormatter
not handling DropEvent
.
I wouldn't call it a wontfix, but the approach in the PR added too much complexity/moving parts. I would love to support this, but it would have to be a simpler approach since the stdlib integration already is a huge pain to maintain and use. Of course, I don't know if such an approach exists.
It seems like the root of the issue stems from the fact that ProcessorFormatter
is implemented as a logging.Formatter
. Thus, it has no ability to make decisions about whether a record should be logged at all. In the PR is a suggestion that seems like the most straightforward approach which would be to deprecate the ProcessorFormatter
in favor of a ProcessorHandler
which can handle everything the formatter was doing but the ability to drop the record entirely if desired.
Steps to reproduce
DropEvent
inpre_chain
.Expected behaviour
The log should be skipped.
Actual behaviour
Raises DropEvent; The exception is not caught.
Comments
I don't know if this is really expected or not. There should be at least a disclaimer in the documentation that states clearly that you shouldn't throw
DropEvent
in pre_chains processors, and you should instead write a stdlibFilter
.However, I reckon there is a way to handle the DropEvent in pre_chain. We could declare a custom
Handler
that proxies everything to theStreamHandler
(or whatever handler is configured), except that we catch/ignore theDropEvent
exception in the overiddenemit
method. This solution implies a tiny overhead on each log, since we have to forward each log entry to the underlying handler.