Manually sent events do not get breadcrumbs from integration
See original GitHub issuePlease mark the type framework used:
- ASP.NET MVC
- ASP.NET Web API (OWIN)
- ASP.NET Core
- WPF
- WinForms
- Xamarin
- Other: Windows Service and Console App
Please mark the type of the runtime used:
- .NET Framework
- Mono
- .NET Core
- Version:
Please mark the NuGet packages used:
- Sentry
- Sentry.Serilog
- Sentry.NLog
- Sentry.Log4Net
- Sentry.Extensions.Logging
- Sentry.AspNetCore
- Version: 2.1.0
I don’t know if this is something that just can’t be avoided, or if I’m just not doing it right. But sometimes I want to sent an event to sentry that falls outside of the criteria I have specified for the NLog integration (e.g. send an event at a lower level than is configured to send to sentry, for a very specific use case such that I wouldn’t want to enable it at that level globally).
When I do this, the resulting event does not have any breadcrumb information except for the breadcrumbs from other manual usages of SentrySdk.CaptureEvent
or SentrySdk.AddBreadCrumb
.
Example event capture:
var logger = LogManager.GetCurrentClassLogger();
logger.Info("I would expect this line to add a breadcrumb to the following event");
var ev = new SentryEvent
{
Message = "blah",
Level = SentryLevel.Info,
Logger = logger.Name,
};
ev.SetExtra("extra", "extra");
ev.SetTag("tag", "Something");
SentrySdk.CaptureEvent(ev);
Should I expect this to work, or would the threading / tasks in the NLog system prevent this from working like I’m expecting it to with Sentry?
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (8 by maintainers)
Top GitHub Comments
@josh-degraw I would also expect your code to work, unless using custom IHub or having activated
<targets async="true">
. Is this the case?@snakefoot, I might do that if that’s the only issue here. No specific reason necessarily, I was just hoping to reduce latency in the app itself so I enabled the async wrapper for all targets since it’s easier to declare it that way. But I guess since sentry itself is asynchronous in how the event queue works anywayit’s probably an unnecessary extra indirection now that you’ve pointed it out. I’ll close this issue for now and try changing that here and see if that fixes the issue.
UPDATE: I made the change and it looks like it worked.