Closed niemyjski closed 1 year ago
I think what we need to do is add a simpler hook that users can wire into that happens after the plugins have run. It would let you easily modify or cancel events right before they are queued to be sent.
@ejsmith this data is deeply nested on the root error object and not easy to get to? What if we just introduced the pattern where for select properties, we looked at DataExclusions? In this case if Modules
is in client.Configuration.DataExclusions
we don't populate them?
I think you can pretty easily disable modules being collected altogether. I think what would be a generally useful feature is if you can see the fully populated event right before it's about to be sent and you could make changes or even decide to cancel sending it all together.
@ejsmith you can do that today with client.OnSubmitting
The event is fully processed, and the next line sees if you cancelled it before enqueuing it.
I was thinking about DataExclusions I kind of feel like that would be magic and cause confusion as to what properties would be taken into account. I think I'd rather just add a flag to the configuration for excluding error module information.
I'm going to close this, if we feel like we need it let's reopen. It would be nice to trim this from our payloads but it does add value. Also, you can write a plugin or use client.OnSubmitting
event handler to remove this data today.
This could be done today by adding a plugin https://github.com/exceptionless/Exceptionless.Net/wiki/Adding-Plugins and inspecting the Error and removing any loaded modules. This would shrink payload sizes as well... This is a customer request.