Repository navigation
fix(hosting): start the SDK during Build() even when the app clears or replaces logger providers - #5772
Merged
Conversation
… replaced UseSentry relied on Sentry's logger provider to start the SDK while the host was built. When an app called ClearProviders() after UseSentry, or replaced the logger factory with Services.AddSerilog(), nothing started the SDK until the host started, so a host that was built but never started captured nothing. SentrySdkInitializer is an IConfigureOptions<HostOptions> that resolves Func<IHub>. The host's constructor reads IOptions<HostOptions>, so it runs during Build() whatever the app did to its logging. SentryHostedService keeps resolving Func<IHub> as a fallback. HostOptions is in Microsoft.Extensions.Hosting, so the package now depends on it, at the lowest version each target needs: one per runtime makes apps that reference an older version fail with NU1605. Refs #5755 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## version7 #5772 +/- ##
=========================================
Coverage 76.17% 76.18%
=========================================
Files 526 527 +1
Lines 19265 19268 +3
Branches 3729 3729
=========================================
+ Hits 14676 14679 +3
Misses 3734 3734
Partials 855 855 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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 generic host's
UseSentrynow starts the SDK while the host is built, even when the app clears or replaces the logger providers. Until now, Sentry's logger provider was what started it duringBuild(). CallingClearProviders()afterUseSentry, or replacing the logger factory withServices.AddSerilog(), left nothing to start the SDK before the host started. A host that was built but never started captured nothing, and code inProgram.csbetweenBuild()andRun()ran without Sentry. One visible effect for those apps is that an invalid DSN now throws fromBuild()instead ofStartAsync(), like it already did for apps with the default logging.SentrySdkInitializeris anIConfigureOptions<HostOptions>that resolvesFunc<IHub>, which is what starts the SDK. The host's constructor readsIOptions<HostOptions>from Microsoft.Extensions.Hosting 3.1 onward, so it runs duringBuild()on both builders, whatever the app did to its logging.SentryHostedServicestill resolvesFunc<IHub>as well. If a host ever stopped readingHostOptionsin its constructor, the SDK would still start before the other hosted services. The two start-order tests now remove the initializer to keep checking that.HostOptionslives in Microsoft.Extensions.Hosting, not in the Abstractions package, so Sentry.Extensions.Hosting now depends on it: 3.1.0 for netstandard2.0 and 8.0.0 for .NET 8 and later. Generic host apps already reference it. I used the lowest version each target needs instead of one per runtime. Pinning 11.0.0 for net11.0 broke our GenericHost sample, which references 9.0.8, with NU1605, and apps that pin an older version would break the same way. In CI only the Windows net48 job runs the netstandard2.0 build, so I also checked it locally against Microsoft.Extensions.Hosting 3.1.0.This is part 1 of the fix discussed in #5755. Logger providers removed by
ClearProviders()still don't come back, and ASP.NET Core and Blazor WebAssembly aren't covered yet.Refs #5755