Open jinohkang-theori opened 11 months ago
Yes, this is pretty much intentional. The event_mapper
takes precedence over the filter, as you can also filter things in it, you just return an EventMapping::Ignore
.
Though I admit the docs might not fully reflect this.
Yes, this is pretty much intentional. The
event_mapper
takes precedence over the filter, as you can also filter things in it, you just return anEventMapping::Ignore
.Though I admit the docs might not fully reflect this.
Thank you for your swift response! I appreciate it, really.
I believe this behavior is part of stable API and guaranteed to stay the same in the foreseeable future. Is this correct? If this is the case, I could submit a PR to document this explicitly.
I believe this behavior is part of stable API and guaranteed to stay the same in the foreseeable future. Is this correct? If this is the case, I could submit a PR to document this explicitly.
Yes, we wouldn’t want to change this behavior suddenly. PRs to improve docs are always appreciated ❤️
Environment
Linux x86_64
Steps to Reproduce
SentryLayer
with bothevent_filter
andevent_mapper
set.event_filter
ignores tracing events belowLevel::ERROR
.event_mapper
always returnsEventMapping::Event(..)
.Level::WARN
(warn!()
).Expected Result
The
warn
event is discarded by the filter; the Sentry instance does not receive any events.Actual Result
The
warn
event is not discarded by the filter; the Sentry instance receives the mapped event.