Most exceptions are logged as System.AggregateException

[skolima]

Running with .NET 4.7.2, with heavy use of Parallel.ForEach. After moving to sentry-dotnet from Raven, most of our exceptions now show up in Sentry dashboard as "System.AggregateException: One or more errors occurred.". Raven used to unpack those if there was just a single inner exception, which made the dashboard a lot more "glanceable".

Now I understand this might be an explicit design choice not to unpack them: in this case, could you please provide a code sample how to preprocess them in the client code (I'm guessing somewhere with filters?)

[bruno-garcia]

Although some of .NET's API will wrap exceptions inAggregateException, simply because more than one exception could have happened at that point (i.e TPL), it's also a valid scenario for a user to throw it's own instance, with a meaningful message and location (stacktrace).
Also, a catch block in between the throw and Sentry capturing it could have added useful stuff into Data. That would also be lost if we simply dropped the AggregateException

With that in mind, it was a design idea to not throw this information away automatically but perhaps shortsighted as for many usages of the TPL like yours this is likely noise only.

It's a fair request to add the possibility to drop AggregateException altogether by default (on 2.0.0 which is breaking) although that will affect event grouping and could be a showstopper to many, I'm afraid.

Another option is to add an opt-in: UnwrapOnlyAggregateException or something with a much better name.

Code doing all that is here:

sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs

Lines 65 to 102 in c777366

	internal IEnumerable<SentryException> CreateSentryException(Exception exception)
	{
	Debug.Assert(exception != null);
	if (exception is AggregateException ae)
	{
	foreach (var inner in ae.InnerExceptions.SelectMany(CreateSentryException))
	{
	yield return inner;
	}
	}
	else if (exception.InnerException != null)
	{
	foreach (var inner in CreateSentryException(exception.InnerException))
	{
	yield return inner;
	}
	}
	var sentryEx = new SentryException
	{
	Type = exception.GetType()?.FullName,
	Module = exception.GetType()?.Assembly?.FullName,
	Value = exception.Message,
	ThreadId = Thread.CurrentThread.ManagedThreadId,
	Mechanism = GetMechanism(exception)
	};
	if (exception.Data.Count != 0)
	{
	foreach (var key in exception.Data.Keys)
	{
	if (key is string keyString)
	{
	sentryEx.Data[keyString] = exception.Data[key];
	}
	}
	}

In case you or someone else in the community like to help with a PR proposing a change. I'd be happy to review and discuss it further.

Until then:

The work around you're looking for would look like this:

private class NoAggregateExceptionSentryEventProcessor : ISentryEventProcessor
{
    public SentryEvent Process(SentryEvent @event)
    {
        @event.SentryExceptions = @event.SentryExceptions
            .Where(e => e.Type != typeof(AggregateException).FullName).ToList();
        return @event;
    }
}

[Tyrrrz]

I think a good solution here would be to automatically flatten aggregate exceptions when captured at system boundaries (i.e. via ASP.NET Core middlware, UnhandledExceptionHandler, or whatever) but not when captured directly using CaptureEvent.

[bruno-garcia]

We should tackle this on 3.0 since we're adding arg names it'll affect grouping.

Lets flatten in in the MainExceptionProcessor with an option to opt-out (back to the original behavior).

[Tyrrrz]

@bruno-garcia I'm trying to understand the code in MainExceptionProcessor but it looks like it already handles aggregate exceptions? Or is it doing something else?

sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs

Lines 59 to 72 in bfb18ac

	if (exception is AggregateException ae)
	{
	foreach (var inner in ae.InnerExceptions.SelectMany(CreateSentryException))
	{
	yield return inner;
	}
	}
	else if (exception.InnerException != null)
	{
	foreach (var inner in CreateSentryException(exception.InnerException))
	{
	yield return inner;
	}
	}

[bruno-garcia]

The problem is that below it returns the exception itself regardless:

sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs

Lines 74 to 81 in bfb18ac

	var sentryEx = new SentryException
	{
	Type = exception.GetType()?.FullName,
	Module = exception.GetType()?.Assembly?.FullName,
	Value = exception.Message,
	ThreadId = Thread.CurrentThread.ManagedThreadId,
	Mechanism = GetMechanism(exception)
	};

[Tyrrrz]

So the goal is to drop AggregateException in this case then?

[bruno-garcia]

@Tyrrrz I believe this is what most folks expect. Would be nice to have a switch to go back to the old behavior.

[mattjohnsonpint]

@bruno-garcia - let's chat about this. Thanks.

[mattjohnsonpint]

To summarize, we would like to add a client-side option to the SDK that will filter out aggregate exceptions, but would still keep all the inner exceptions.