SentrySdk.CaptureException should add a breadcrumb for future exceptions
Closed this issue · 5 comments
Problem Statement
It appears that when you call SentrySdk.CaptureException, it does not add a breadrcrumb of itself, which means the next SentrySdk.CaptureException call does not show the previous exception in the dashboard. This seems like critical information to have by default, as its quite common for one exception to trigger another if things aren't handled well, and you will lose that contextual awareness that this exception was caused by a different exception happening.
Solution Brainstorm
No response
Ha, that's a super valid point! I never realized the SDK not doing that! Coming from the Unity SDK I just expected it to be there. The only instances I found where the Core SDK would add breadcrumbs itself were the BeforeSend and BeforeSendTransaction callbacks to let users know that it blew up:
sentry-dotnet/src/Sentry/SentryClient.cs
Lines 208 to 212 in 5e54f08
sentry-dotnet/src/Sentry/SentryClient.cs
Lines 443 to 447 in 5e54f08
@bruno-garcia @jamescrosswell any thoughts on this? I can see this being an opt-in feature?
We do this on the logging libraries. It makes sense to me, I think it was an oversight.
But take into account that we'd be double writing in the logging integrations, so we'd need to remove those.
Would need a refactor. Or if we don't want to change the current behavior on the logging libraries, we could skip this new breadcrumb if the event was written by one of our logging libraries (by for example checkign against the sdk name)
Either of the suggestions that bruno made sound good. Especially if it doesn't require/cause any user-facing changes (ie have the logging libraries do the right thing automatically)
That would not even require being added in the next mayor.
I think it's cleanest to do it once/always when capturing an exception and make sure the logging libraries either capture an exception or drop a breadcrumb (not both).