feat: Microsoft.Extensions.Logging integration no longer initializes the SDK - #5595
Draft
jamescrosswell wants to merge 2 commits into
Draft
jamescrosswell wants to merge 2 commits into
jamescrosswell wants to merge 2 commits into
Conversation
…the SDK Completes the logging-integration part of #5245. The MEL integration now only wires up the logger providers; Sentry has to be initialized separately. Unlike Serilog, NLog and log4net, SentryLoggingOptions keeps deriving from SentryOptions, because SentryAspNetCoreOptions, SentryMauiOptions and SentryBlazorOptions derive from it and those integrations do initialize the SDK. InitializeSdk therefore stays as internal plumbing, now defaulting to false and opted into by the framework integrations that own it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## feat/no-init-from-logging-log4net-5245 #5595 +/- ##
==========================================================================
+ Coverage 74.56% 74.65% +0.09%
==========================================================================
Files 514 517 +3
Lines 18728 18743 +15
Branches 3641 3637 -4
==========================================================================
+ Hits 13964 13993 +29
+ Misses 3891 3874 -17
- Partials 873 876 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
… framework options SentryLoggingOptions no longer derives from SentryOptions, matching the Serilog and NLog options: it carries only the log levels and entry filters. SentryAspNetCoreOptions, SentryMauiOptions and SentryBlazorOptions now derive from a new abstract SentryHostOptions, which keeps MinimumEventLevel, MinimumBreadcrumbLevel, ConfigureScope and AddLogEntryFilter by passing them through to an inner SentryLoggingOptions, so existing UseSentry callbacks and configuration keys keep working. InitializeSdk is removed. Integrations that initialise through DI call AddSentry<TOptions>; MAUI, which initialises in SentryMauiInitializer, uses an internal non-initialising overload. ConfigureScope callbacks are applied right after the SDK is initialised instead of when the MEL logger provider is built. Also fixes Blazor WebAssembly's logger ignoring the logging settings from UseSentry (it was built from a separate, default IOptions<SentryLoggingOptions>), and structured logs from plain MEL taking default attributes from options the SDK was not initialised with. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
Microsoft.Extensions.Loggingportion of #5245, stacked on #5592 (log4net) and following the same design.AddSentrynow only wires up the logger providers; Sentry has to be initialized separately viaSentrySdk.Init,UseSentry, etc.This is the last of the four logging integrations, so it closes the issue.
Closes #5245
Changelog Entry
Microsoft.Extensions.Loggingintegration no longer initializes the SDK. Sentry must now be initialized separately from the logging integration (usingSentrySdk.InitorUseSentry) - #5595MinimumEventLevel,MinimumBreadcrumbLevel, log entry filters andConfigureScopecallbacks set inUseSentry- #5595Breaking changes
SentryLoggingOptionsno longer derives fromSentryOptions, matching the Serilog and NLog options. It carries onlyMinimumBreadcrumbLevel,MinimumEventLeveland log entry filters, sobuilder.Logging.AddSentry(o => o.Dsn = "…")now fails to compile instead of silently doing nothing. Core SDK settings go on the options used to initialize Sentry.SentryLoggingOptions.ConfigureScopeis removed. CallSentrySdk.ConfigureScopeafter initializing Sentry.ILoggingBuilder.AddSentry(string dsn)is removed.ILoggerFactory.AddSentry(…)no longer initializes Sentry, replaces the current hub, or assigns aMelDiagnosticLoggeras the SDK'sDiagnosticLogger.InitializeSdkis removed, from code and from configuration binding.SentryAspNetCoreOptions,SentryMauiOptionsandSentryBlazorOptionsnow derive from a new abstractSentryHostOptions : SentryOptions. They still haveMinimumBreadcrumbLevel,MinimumEventLevel,ConfigureScopeandAddLogEntryFilter, and the same keys still bind from theSentryconfiguration section, so existingUseSentrycallbacks andappsettings.jsonfiles keep working. Code that treats them as aSentryLoggingOptionsno longer compiles.ServiceCollectionExtensions.AddSentry<TOptions>now requiresTOptions : SentryHostOptions.ConfigureScopecallbacks on the framework options now run when Sentry is initialized, rather than when the Sentry logger provider is first created.Before:
After:
Fixes
UseSentry. Blazor registered the plain MEL logger provider, which dependency injection built from a separate, defaultIOptions<SentryLoggingOptions>rather than theSentryBlazorOptionsconfigured inUseSentry.MinimumEventLevel,MinimumBreadcrumbLevel, log entry filters andConfigureScopewere all silently ignored by the logger; SDK initialization itself was unaffected. The same bug exists onmain.sentry.environment,sentry.releaseandserver.addresswere read fromSentryLoggingOptions, which the SDK was no longer initialized with. The structured logger now reads them from the hub.Notes for review
Why
SentryHostOptions.SentryLoggingOptionswas doing two jobs: configuring the MEL logger, and acting as the base class for integrations that initialize the SDK. Splitting them is what letsSentryLoggingOptionsgo standalone. The host options pass the log levels and filters through to an innerSentryLoggingOptionsinstance (the same object, not a copy), and that is what their logger providers receive.Why abstract. It's the natural options type for a generic-host init path (Add a non-logging way to initialise Sentry in generic host apps #5572). Making it concrete later is additive; the reverse would be breaking. It lives in
Sentry.Extensions.Loggingbecause that's the one package ASP.NET Core, MAUI and Blazor all reference. Where it ultimately belongs is the packaging question Add a non-logging way to initialise Sentry in generic host apps #5572 raises.ConfigureScopetiming. For MAUI and Blazor, the only thing that applied these callbacks used to be the MEL logger provider's constructor, gated onhub.IsEnabledwhen the provider was built. They're now applied right after init: inAddSentry<TOptions>'s hub factory (ASP.NET Core, Blazor) and inSentryMauiInitializer(MAUI). ASP.NET Core still also applies them per request inSentryMiddleware, and gRPC in its interceptor.InitializeSdk. MAUI initializes inSentryMauiInitializer, so it calls an internal non-initializing overload ofAddSentry<TOptions>instead of setting a flag. Tests that setInitializeSdk = falseto avoid initializing now useDisableSdkDsnValue.UseSentry_OptionsNotInitializeSdk_DisabledSdktested the flag itself and is deleted;UseSentry_DisableDsn_DisabledSdkstill covers a disabled SDK.Blazor registrations.
UseSentrynow delegates to an internalILoggingBuilderextension so it can be unit tested (WebAssemblyHostBuilderneeds a browser runtime). The providers are registered by factory so they keep their existing types, and with them the existing provider alias and filter configuration. Configuration binding moved to a smallSentryHostOptionsSetup<TOptions>inSentry.Extensions.Logging, which has the configuration-binding source generator enabled, since Blazor WASM is trimmed.New tests.
ConfigureScopecallbacks, and the non-initializing path doesn't.ConfigureScopedata reaches events. Nothing tested that before.MinimumEventLevel.Each test was checked to fail with its fix reverted.
The
ApplyDefaultTagstests only usedSentryLoggingOptionsas a vehicle for a coreSentryOptionsmethod; they moved toSentryOptionsTests.The structured-logger tests now give their mocked hub options through
SentryOptionsForTestingOnlyand reset it afterwards. The MEL provider test previously passed only because another test class happened to leave it set.builder.Logging.AddSentry(dsn)was the only way to initialize Sentry in a generic-host app, sosamples/Sentry.Samples.GenericHostnow callsSentrySdk.Initdirectly. Add a non-logging way to initialise Sentry in generic host apps #5572 tracks the replacement and should land before this ships.ApiApprovalTests.Run.Net4_8can't regenerate on macOS. It was byte-identical to the other snapshots before this change, so it's a copy of the regenerated one.🤖 Generated with Claude Code