You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered an issue using Serilog.Exceptions for certain exception types which contain very large properties that exceed the max log size in New Relic (where I ship logs) causing the logs to not be parsed correctly.
In the first case, I am logging a custom Exception with an InnerException of OptimisticConcurrencyException, so the JSON-formatted log looks like this:
I'm happy to make contributions to handle both these exceptions without logging these large properties, but wanted to confirm the best approach before starting.
My initial thought was to write custom destructurers (one for each exception) that explicitly ignore the large properties. Is this the best way to handle it?
Does the nested nature of the first case present any additional concerns, or can it be handled in the same way as the second case?
Also, happy to break this into 2 separate issues if that is preferable.
The text was updated successfully, but these errors were encountered:
Regarding the first type System.Data.Entity.Core.OptimisticConcurrencyException, am I right in thinking thats the older EF6? If its EF Core, we have an EF package that we should add a custom destructurer to.
We could also add a new package and handle AutoMapper as we have done for Refit. Although, having to add custom destructurers for third party libraries has always left a bad taste in my mouth.
Also FYI, I believe you can use Serilog.Expressions to filter out long properties yourself.
I encountered an issue using Serilog.Exceptions for certain exception types which contain very large properties that exceed the max log size in New Relic (where I ship logs) causing the logs to not be parsed correctly.
In the first case, I am logging a custom Exception with an InnerException of OptimisticConcurrencyException, so the JSON-formatted log looks like this:
In the second case, the AutoMapper exception itself is being logged:
I'm happy to make contributions to handle both these exceptions without logging these large properties, but wanted to confirm the best approach before starting.
Also, happy to break this into 2 separate issues if that is preferable.
The text was updated successfully, but these errors were encountered: