fix(serilog): logs from application namespaces beginning with "Sentry" are discarded by jamescrosswell · Pull Request #5456 · getsentry/sentry-dotnet

jamescrosswell · 2026-07-29T05:29:53Z

Summary

SentrySink discarded any Serilog event whose SourceContext started with "Sentry.". That heuristic dates back to 2019 ("don't log self log") and is meant to stop the SDK's own diagnostics looping back into Sentry — but it also matches application code. An app logging under, say, Sentry.Samples.AspNetCore.Serilog.Program had its log events dropped before anything was created: no event, no breadcrumb, no structured log, and therefore no event processors run. That last symptom is how #5265 was reported, but ISentryEventProcessor was never the problem.

Our own samples/Sentry.Samples.AspNetCore.Serilog uses that namespace, so the sample demonstrating the ILogger path was silently broken — which is where the reporter picked it up.

The filter can't simply be removed. MelDiagnosticLogger routes SDK diagnostics through ILogger<ISentryClient> whenever Debug is enabled (ApplicationBuilderExtensions.cs), and with Serilog as the MEL backend that's a genuine feedback loop. The isReentrant guard in the sink doesn't cover it, because the transport logs from the background worker thread.

So the check now matches the namespace roots the SDK actually owns, rather than a bare "Sentry." prefix.

Notes for review

The root list is generated, not hand-maintained. A GenerateSentrySdkNamespaces target in Sentry.csproj reads the package list out of .craft.yml at build time and emits SentrySdkNamespaces.g.cs. No reflection (AOT/trimming-safe) and no list to keep in sync as packages are added. .craft.yml's line order is fixed, so output is deterministic. The target hard-errors rather than emitting an empty list, since an empty list would silently restore the loop risk.
The core Sentry package can't be a prefix root. All of its types live under Sentry. — and so does user code — so treating it as a prefix would reproduce the original bug. Core has no logging dependency of its own, and the only category it ever logs under is Sentry.ISentryClient (from MelDiagnosticLogger), so that plus a bare Sentry are matched exactly. This is the one hardcoded string in the change; it's commented next to the thing that produces it.
Sentry.Extensions.Logging is included deliberately. SentryLogger.IsFromSentry() carried the same heuristic plus a #if DEBUG carve-out for Sentry.Samples., which only ever helped samples built from source — anyone on the released package was still affected. Both integrations now share one helper. Sentry.NLog and Sentry.Log4Net have never had this filter at all; that asymmetry is left as-is here.
.craft.yml gains Sentry.Maui.CommunityToolkit.Mvvm, which is packable but was missing from the registry list. Worth a second pair of eyes: it's a release-config change riding along with a bug fix, and it means the release registry starts tracking that package... main reason for including it in this PR is that we're using craft.yml to generate the list of namespaces that we match against for log filtering.

…ing with "Sentry" The Serilog sink dropped any log event whose SourceContext started with "Sentry.", a heuristic meant to keep the SDK's own diagnostics from looping back into Sentry. It also matched application code, so an app logging under e.g. "Sentry.Samples.AspNetCore.Serilog.Program" had its events silently discarded - no event, no breadcrumb, no structured log, and no event processors run. Our own ASP.NET Core Serilog sample is written in exactly that namespace. The filter is still needed: MelDiagnosticLogger routes SDK diagnostics through ILogger<ISentryClient> when Debug is enabled, which Serilog would otherwise feed straight back in. So instead of matching a bare prefix, match the namespace roots the SDK actually owns. Those are generated at build time from the package list in .craft.yml, so the list can't go stale as packages are added. The core "Sentry" package can't be a prefix root - all its types live under "Sentry.", as does user code - so it is matched exactly, along with the one category core ever logs under. Sentry.Extensions.Logging shared the same heuristic, including a #if DEBUG carve-out for "Sentry.Samples." that only ever helped samples built from source. Both integrations now use the same helper. Also adds the missing Sentry.Maui.CommunityToolkit.Mvvm entry to .craft.yml. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

codecov · 2026-07-29T05:46:16Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.70%. Comparing base (8d4d3f6) to head (252fe48).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5456   +/-   ##
=======================================
  Coverage   74.69%   74.70%           
=======================================
  Files         512      513    +1     
  Lines       18722    18729    +7     
  Branches     3660     3663    +3     
=======================================
+ Hits        13985    13992    +7     
  Misses       3865     3865           
  Partials      872      872

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>

alexander-alderman-webb

The src/Sentry/Internal/SentrySdkNamespaces.cs logic looks sound to me.

### Context - Same failure mode as #223 (`Sentry.Hangfire`) and #221 (`Sentry.Extensions.AI`) - Follow-up to getsentry/sentry-dotnet#5456 - Tracking issue: getsentry/sentry-dotnet#5495 ### Summary `Sentry.Maui.CommunityToolkit.Mvvm` has shipped on NuGet since 5.8.0 but was never added here. getsentry/sentry-dotnet#5456 added it to sentry-dotnet's `.craft.yml` registry target, and the 6.9.0 publish then aborted ([run 32010411662](https://github.com/getsentry/publish/actions/runs/32010411662)): ``` [error] "name" is required for new package "nuget:Sentry.Maui.CommunityToolkit.Mvvm". Add `name` to the registry target config in your .craft.yml. ``` Craft treats a package as new only when its `latest.json` is missing, so seeding the directory here makes the bare `.craft.yml` key work exactly as it does for the other 18 sentry-dotnet packages. The failure isn't scoped to this one package — `updateVersionInRegistry` throws before craft commits anything, so the whole registry target rolls back. Every sentry-dotnet package is currently still pinned at 6.8.0 here, two releases into 6.9.0 being live on NuGet. ### Notes for review - **Seeded at 6.8.0, not 6.9.0, deliberately.** Craft aborts with `Version file for "6.9.0" already exists. Aborting.` if the version being published is already present — which would roll the target back again and leave all 19 packages stuck at 6.8.0. Seeding the previous version (which the package did ship) lets the retry create 6.9.0 and re-point the symlinks. #223 did the same, seeding `6.0.0-rc.2-prerelease`. - `canonical` has to match the `.craft.yml` key exactly or craft errors on the consistency check in `getUpdatedManifest`. - `created_at` is the value craft wrote for the sibling packages in the 6.8.0 release, since it's the same release event. - Symlinks generated with `bin/sync-links`, not by hand. I also re-ran the full `make sync-all-links` (via `xargs`, as the bare `find` blows the argument limit on macOS) and confirmed it reproduces the committed tree exactly, so the CI sync check should be clean. - No `sdks/sentry.dotnet.maui.communitytoolkit.mvvm` symlink. Every other dotnet package has one, but this package doesn't emit its own `sdk_info.name` — its events go out as `sentry.dotnet.maui` — so the entry would name something nothing reports. Happy to add it if uniformity is preferred. ### Relationship to getsentry/sentry-dotnet#5496 #5496 approaches the same failure from the other side: it gives sentry-dotnet's `.craft.yml` the `name`/`packageUrl`/`mainDocsUrl` that craft needs to create manifests itself — for *every* package, not just this one, so the next new package doesn't repeat this. The two are complementary rather than exclusive. This PR unblocks the 6.9.0 retry now; #5496 stops it happening again. If both land, this package's `.craft.yml` entry is simply belt-and-braces — craft applies the config over the manifest on every release either way. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

jamescrosswell mentioned this pull request Jul 29, 2026

Sentry.Serilog Does Not Use ISentryEventProcessor When Microsoft.Extensions.Logging.ILogger Is Used #5265

Closed

jamescrosswell changed the title ~~fix(serilog): stop discarding logs from application namespaces beginning with "Sentry"~~ fix(serilog): logs from application namespaces beginning with "Sentry" are discarded Jul 29, 2026