-
-
Notifications
You must be signed in to change notification settings - Fork 226
Ensure mechanism data is not fully overwritten #4106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@jamescrosswell how come this was turned into a draft? The CI failures here don't have anything to do with the PR itself. I've merged in the latest main in case I'm missing something needed for the PR to be finished |
jamescrosswell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good... I think we should update the expectations for our unit tests to match the code changes though.
There's this one - could may be tweak it and/or add another test case:
| [Collection(nameof(SentrySdkCollection))] | |
| public class AspNetCoreIntegrationTests : SerilogAspNetSentrySdkTestFixture | |
| { | |
| [Fact] | |
| public async Task UnhandledException_MarkedAsUnhandled() | |
| { | |
| var handler = new RequestHandler | |
| { | |
| Path = "/throw", | |
| Handler = _ => throw new Exception("test") | |
| }; | |
| Handlers = new[] { handler }; | |
| Build(); | |
| await HttpClient.GetAsync(handler.Path); | |
| Assert.Contains(Events, e => e.Logger == "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware"); | |
| Assert.Collection(Events, @event => Assert.Collection(@event.SentryExceptions, x => Assert.False(x.Mechanism?.Handled))); | |
| } | |
| } |
|
@jamescrosswell What's your thinking for the tweak though? The code doesn't change the behaviour. It just prevents the previous data from being completely overwritten. I'm not even sure what I would be adjusting here. |
At the moment, the delegate for handler in that test just throws an exception. If instead we throw, catch, add some exception.Data and rethrow, then we would expect the exception data to be retained in the SentryException.Mechanism (not overwritten). |
|
@jamescrosswell I just added some basic tests directly around the AspNetCoreExceptionProcessor |
Resolves #4027
ASP.NET Core's AspNetCoreExceptionProcessor was overwriting the Mechanism and thereby clearing any exception data that may have been recorded.