feat: User.Id can now be overriden (set to null) in Global mode#5039
feat: User.Id can now be overriden (set to null) in Global mode#5039jamescrosswell wants to merge 15 commits intomainfrom
Conversation
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Breaking Changes 🛠
Features ✨
Fixes 🐛
Dependencies ⬆️Deps
Other
🤖 This preview updates automatically when you update the PR. |
| ] | ||
| }, | ||
| { | ||
| Message: Starting BackpressureMonitor. |
There was a problem hiding this comment.
These were never really part of the test anyway (which is to ensure all the default integrations get registered)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5039 +/- ##
==========================================
+ Coverage 73.87% 74.07% +0.20%
==========================================
Files 506 507 +1
Lines 18247 18255 +8
Branches 3564 3568 +4
==========================================
+ Hits 13480 13523 +43
+ Misses 3891 3865 -26
+ Partials 876 867 -9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR adjusts how User.Id is populated from InstallationId when Global Mode is enabled, so that applications can explicitly clear/override the value (e.g., set it to null) without it being re-applied during event enrichment.
Changes:
- Add a new
GlobalRootScopeIntegrationdefault integration that setsscope.User.Idfromoptions.InstallationIdat startup (Global Mode only). - Update
Enricherto not apply theInstallationIdfallback in Global Mode (so user overrides aren’t re-written). - Update/extend tests and Verify snapshots to account for the new default integration and changed behavior.
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
src/Sentry/Integrations/GlobalRootScopeIntegration.cs |
New integration to set User.Id on the root scope in Global Mode. |
src/Sentry/Internal/Enricher.cs |
Stops applying InstallationId fallback when Global Mode is enabled. |
src/Sentry/SentryOptions.cs |
Registers the new integration as a default integration. |
test/Sentry.Tests/Integrations/GlobalRootScopeIntegrationTests.cs |
Adds tests covering the new integration and updated enricher behavior. |
test/Sentry.Tests/SentryClientTests.cs |
Adjusts tests around fallback User.Id behavior. |
test/Sentry.Tests/SentryOptionsTests.verify.cs + *.verified.txt |
Narrows snapshot scope to integration-registration logs and updates expected output. |
src/Sentry/PlatformAbstractions/FrameworkInfo.cs |
Adds an additional .NET Framework release key mapping for 4.8.1. |
| // Set by the GlobalRootScopeIntegration In global mode so that it can be overridden by the user. | ||
| // In non-global mode (e.g. ASP.NET Core) the enricher sets it here as a fallback. | ||
| if (!_options.IsGlobalModeEnabled) | ||
| { | ||
| eventLike.User.Id ??= _options.InstallationId; | ||
| } | ||
|
|
There was a problem hiding this comment.
With this change, the InstallationId fallback for User.Id is no longer applied when IsGlobalModeEnabled is true. That means scenarios that rely on Enricher without going through Hub initialization/integrations (e.g., apps constructing SentryClient directly) will no longer get the previous default User.Id behavior in global mode. If that behavior needs to remain, consider an alternative that still allows explicit clearing (e.g., apply the fallback when creating the initial Scope/root scope, or introduce an explicit option/flag indicating whether the fallback should be applied).
| // Set by the GlobalRootScopeIntegration In global mode so that it can be overridden by the user. | |
| // In non-global mode (e.g. ASP.NET Core) the enricher sets it here as a fallback. | |
| if (!_options.IsGlobalModeEnabled) | |
| { | |
| eventLike.User.Id ??= _options.InstallationId; | |
| } | |
| // User.Id can be set by the GlobalRootScopeIntegration in global mode or by user code. | |
| // The enricher still provides the InstallationId-based fallback here, but it will not override | |
| // any value that was already set. | |
| eventLike.User.Id ??= _options.InstallationId; |
There was a problem hiding this comment.
I don't think there's a scenario where someone uses a SentryClient independent of the Hub... so this isn't a real concern.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Thank you for the PR! |
| return; | ||
| } | ||
|
|
||
| hub.ConfigureScope(scope => scope.User.Id ??= options.InstallationId); |
There was a problem hiding this comment.
question: compliant with new PII rules?
See https://develop.sentry.dev/sdk/foundations/client/data-collection/.
I haven't checked the spec yet ... currently in the draft phase ... need to go though it.
I just wanted to make sure we don't paint ourselves into a corner when - later this year - we implement the new PII rules via a new dataCollection-Options.
There was a problem hiding this comment.
Without the installation id, some functionality like Session Health simply doesn't work. So I can't see how we can avoid setting this.
This PR also doesn't introduce the collection of any new information - it just shifts when we're collecting it. So if we no longer want to generate installation ids and send these with events etc. that's fine - but I don't think related to this PR (that would be a separate issue and separate PR in the backlog).
Arguably this PR improves the situation since previously users couldn't opt out of the installation id being set/collected. Now, since we set it early, they can override it by nulling it out if they want.
| {533320, "4.8.1"}, | ||
| {533325, "4.8.1"} | ||
| {533325, "4.8.1"}, | ||
| {533509, "4.8.1"} |
There was a problem hiding this comment.
question: how did you notice this?
CI just started to fail when a new servicing update is applied to the runners?
There was a problem hiding this comment.
I think I ran the unit tests on my Windows box which is running the latest version of Windows and service packs, which broke the tests. Presumably those are now hitting the CI runners.
- Add Scope + SubstituteConfigureScope to the disabled test, with assertion that scope.User.Id remains null - Add hub.Received(1).ConfigureScope assertion to both enabled tests Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Stefan Pölz <38893694+Flash0ver@users.noreply.github.com>
- Use nameof(GlobalRootScopeIntegration) in Skip.If messages for easier navigation - Move comment to after // Arrange in CaptureEvent_UserIsNull_SetsFallbackUserId to match CaptureTransaction_UserIsNull_SetsFallbackUserId Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Resolves #4172