Simplify `PerTraceSettings.GetServiceName()` #7532

andrewlock · 2025-09-18T12:34:45Z

Summary of changes

Don't pass a Tracer instance to PerTraceSettings.GetServiceName() (as it's not required)

Reason for change

Cleanup/simplify the code.

#7530 exposes MutableSettings and DefaultServiceName on PerTraceSettings. Reading DefaultServiceName was the only reason GetServiceName() took a Tracer, so this is now uneccessary.

Implementation details

Use MutableSettings.DefaultServiceName directly inside PerTraceSettings.GetServiceName()
Stop passing in Tracer instance
Cleanup usages

Test coverage

Covered by existing, just a refactoring

Other details

Could have done it as part of #7530 but trying to keep things small!

https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack

datadog-official · 2025-09-18T13:29:42Z

⚠️ Tests

⚠️ Warnings

❄️ 1 New flaky test detected

SubmitsTraces from Datadog.Trace.ClrProfiler.IntegrationTests.StackExchangeRedisTests (Datadog)

Results do not match.
Differences:
Received: StackExchangeRedisTests.Latest.SchemaV0.received.txt
Verified: StackExchangeRedisTests.Latest.SchemaV0.verified.txt
Compare Result:
  [
    {
      TraceId: Id_1,
      SpanId: Id_2,
      Name: redis.command,
...

ℹ️ Info

🧪 All tests passed

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 7655779 | Docs | Was this helpful? Give us feedback!}

dd-trace-dotnet-ci-bot · 2025-09-18T13:52:37Z

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing the following branches/commits:

Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times:

Welch test with statistical test for significance of 5%
Only results indicating a difference greater than 5% and 5 ms are considered.

Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard.

Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph).

gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (72ms)  : 71, 73
     .   : milestone, 72,
    master - mean (72ms)  : 71, 73
     .   : milestone, 72,

    section Baseline
    This PR (7532) - mean (68ms)  : 67, 69
     .   : milestone, 68,
    master - mean (68ms)  : 66, 70
     .   : milestone, 68,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (1,060ms)  : 981, 1140
     .   : milestone, 1060,
    master - mean (1,046ms)  : 1011, 1080
     .   : milestone, 1046,

gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (106ms)  : 105, 107
     .   : milestone, 106,
    master - mean (106ms)  : 105, 107
     .   : milestone, 106,

    section Baseline
    This PR (7532) - mean (105ms)  : 103, 108
     .   : milestone, 105,
    master - mean (105ms)  : 103, 108
     .   : milestone, 105,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (741ms)  : 717, 764
     .   : milestone, 741,
    master - mean (740ms)  : 718, 762
     .   : milestone, 740,

gantt
    title Execution time (ms) FakeDbCommand (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (101ms)  : 99, 102
     .   : milestone, 101,
    master - mean (101ms)  : 99, 102
     .   : milestone, 101,

    section Baseline
    This PR (7532) - mean (100ms)  : 98, 102
     .   : milestone, 100,
    master - mean (100ms)  : 98, 102
     .   : milestone, 100,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (775ms)  : 736, 813
     .   : milestone, 775,
    master - mean (778ms)  : 733, 822
     .   : milestone, 778,

gantt
    title Execution time (ms) FakeDbCommand (.NET 8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (93ms)  : 91, 95
     .   : milestone, 93,
    master - mean (93ms)  : 92, 94
     .   : milestone, 93,

    section Baseline
    This PR (7532) - mean (92ms)  : 90, 95
     .   : milestone, 92,
    master - mean (92ms)  : 90, 94
     .   : milestone, 92,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (658ms)  : 645, 671
     .   : milestone, 658,
    master - mean (662ms)  : 651, 673
     .   : milestone, 662,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (197ms)  : 194, 199
     .   : milestone, 197,
    master - mean (198ms)  : 193, 203
     .   : milestone, 198,

    section Baseline
    This PR (7532) - mean (193ms)  : 190, 197
     .   : milestone, 193,
    master - mean (193ms)  : 188, 197
     .   : milestone, 193,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (1,168ms)  : 1110, 1225
     .   : milestone, 1168,
    master - mean (1,169ms)  : 1115, 1223
     .   : milestone, 1169,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (278ms)  : 274, 282
     .   : milestone, 278,
    master - mean (278ms)  : 272, 284
     .   : milestone, 278,

    section Baseline
    This PR (7532) - mean (276ms)  : 273, 280
     .   : milestone, 276,
    master - mean (279ms)  : 272, 285
     .   : milestone, 279,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (941ms)  : 895, 987
     .   : milestone, 941,
    master - mean (944ms)  : 899, 990
     .   : milestone, 944,

gantt
    title Execution time (ms) HttpMessageHandler (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (280ms)  : 276, 284
     .   : milestone, 280,
    master - mean (281ms)  : 276, 285
     .   : milestone, 281,

    section Baseline
    This PR (7532) - mean (280ms)  : 274, 285
     .   : milestone, 280,
    master - mean (280ms)  : 275, 285
     .   : milestone, 280,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (1,000ms)  : 972, 1029
     .   : milestone, 1000,
    master - mean (996ms)  : 958, 1034
     .   : milestone, 996,

gantt
    title Execution time (ms) HttpMessageHandler (.NET 8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7532) - mean (270ms)  : 266, 274
     .   : milestone, 270,
    master - mean (270ms)  : 266, 273
     .   : milestone, 270,

    section Baseline
    This PR (7532) - mean (270ms)  : 266, 274
     .   : milestone, 270,
    master - mean (270ms)  : 264, 275
     .   : milestone, 270,

    section CallTarget+Inlining+NGEN
    This PR (7532) - mean (856ms)  : 830, 882
     .   : milestone, 856,
    master - mean (865ms)  : 842, 888
     .   : milestone, 865,

## Summary of changes Rebuild and re-assign `MutableSettings` when dynamic config (remote or config in code) changes. ## Reason for change This is part of a general stack to extract the "mutable" configuration from static config that is fixed for the lifetime of the app. In the [previous PR](#7522) we moved mutable settings to their own type, but otherwise left things unchanged and just rebuilt everything whenever anything changes. In this PR we move towards combining the dynamic/code configuration, handling changes by _only_ rebuilding the `MutableSettings` (not `TracerSettings`) and handling all the fallout that causes for telemetry. This is very much still a "stop gap"; we still rebuild everything (_except_ the `TracerSettings` object) when these settings changes. ## Implementation details - Create "global" config sources for dynamic settings and code settings - There's actually a bug today where we clobber dynamic settings if we change things in code because we're not storing the sources globally. - When dynamic config or config in code changes - Create a new `MutableSettings` object based only on dynamic sources (with a fallback for the "static" values) - For config in code, we also check for changes to `ExporterSettings` - If there's no discernable changes, bail out - no need to tear down the world - If there _are_ changes, Mutate `TracerSettings`, and do the normal "reconfigure everything" - Remove the (now unused `ImmutableDynamicSettingsTests`) Note that there are technically some behaviour changes in this PR: - `useDefaultSources: false` only ignores env vars etc for values that can be set through code. Other settings will always use the default sources. - `StatsComutationEnabled` can not be _set_ via code. ## Test coverage This is still all technically a "refactoring", so should be covered by existing tests 🤞 ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7652 - #7525 👈 - #7530 - #7532 - #7543 - #7544

@anna-git

## Summary of changes - Expose `DefaultServiceName` on `MutableSettings` instead of on `TracerManager` - Expose `MutableSettings` on `PerTraceSettings` ## Reason for change The `DefaultServiceName` depends on `ServiceName`, which can change at runtime, so `MutableSettings` seems like the best place for it (eventually we will only have a single `TracerManager` and `TracerSettings` per lifetime > Note that this also solves an existing edge-case bug when customers do config in code and already-finished traces are serialized with the "incorrect" default service name. ## Implementation details Mostly commit-by-commit but: - Move the "fallback application name" calculation to a helper class - Expose the fallback application name on `TracerSettings` - Created as a `Lazy<>` because this calculation can be kind of expensive, and isn't necessary if the customer specifies a service name. - Exposed on `TracerSettings` because it doesn't change - Expose `DefaultServiceName` on `MutableSettings` instead of `TracerManager`. - Update usages to point to the new location Additionally, there are some places where I believe we were "incorrectly" using the `DD_SERVICE` value, and ignoring the real fallback name. - [x] Service Discovery's `StoreTracerMetadata` - @anna-git can you confirm if I'm correct that this _should_ be using the "calculated" service name as a fallback? - [x] `TraceExporterConfiguration` - @ganeshnj, same question, can you confirm that we should be passing the "calculated" service name, not just the "explictly set" service name? One additional aspect I think we should consider: - Currently we're calling `NormalizeService(serviceName)` in a few places. Is there any reason we shouldn't be _always_ normalizing the service name? - e.g. why don't we normalize `DefaultServiceName` automatically? ## Test coverage Covered by existing tests generally ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 👈 - #7532 - #7543 - #7544

…ropriate (#7543) ## Summary of changes Fix usages of `Tracer.Instance.Settings` to use `Tracer.Instance.CurrentTracerSettings.Settings` where appropriate ## Reason for change This PR "fixes" the places that were previously grabbing the environment/service etc from `TracerSettings` to use the `MutableSettings` exposed via `CurrentTracerSettings` instead, as the location where these settings will ultimately exist. This is effectively still just a refactoring, but prepares for the point where these settings aren't exposed on `TracerSettings` at all. The updates in this PR are for cases where you _don't_ have long-lived services, and rather need to do ad-hoc `Tracer.Instance` grabbing of the setting values in a global context. Note too that many of these places _could_ be updated in the future to subscribe to changes if that provides performance benefits. Also note that I elected not to change most calls to `IsIntegrationEnabled()` etc in this PR as there are hundreds of locations. The follow up PR handles that Also found a few cases that were incorrectly assuming that these values cannot change. Marked them with 'TODO: Subscribe to changes in settings' ## Implementation details - Mostly find and replace to use `CurrentTracerSettings.Settings` - Occasional extraction of a variable where it makes sense to avoid repeated access - Functionally identical currently (where `MutableSettings` is replaced on `TracerSettings`) but will be a required change once we stop replacing `TracerManager`. ## Test coverage Covered by existing tests ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 👈 - #7544

…tIntegrationAnalyticsSampleRate()` (#7544) ## Summary of changes Fix usages of `IsIntegrationEnabled()`, `IsErrorStatusCode()`, and `GetIntegrationAnalyticsSampleRate()` to use `MutableSettings` instead of `TracerSettings` ## Reason for change These functions are dependent on `MutableSettings`, and are exposed there, so making sure we call the methods there, and remove the delegation from `TracerSettings` entirely. ## Implementation details - Find and replace usages - Remove the old delegating methods ## Test coverage Just a refactor, so covered by existing tests ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 👈 - #7695

…ndows (#7721) ## Summary of changes Enforces that you can't _change_ the `AgentUri` to be a UDS Uri if you're on Windows ## Reason for change The trace exporter doesn't work with UDS on Windows, so we have a check in `TracerSettings` that disables the pipeline if we find this scenario. However, user's can still _change_ the agent URI at runtime in code (😭). We currently assume that the data pipeline won't be toggled at runtime (we _do_ allow for reconfiguring it in general, but not for completely removing or reintroducing). Changing this to allow the scenario would be a pain, so instead this PR blocks you from setting a UDS URI in code if you're on Windows. The good news is that as far as I can tell, noone does this today, so while _technically_ it could be considered a breaking change, I think it's ok. ## Implementation details - Throw an `ArgumentException` in the Datadog.Trace.Manual library, if you're on Windows (or .NET FX) and you try to set a UDS agent URI (using the same "detection" we do in `ExporterSettings`. - Add a check in the Instrumentation of `Tracer.Configure()` to make sure it hasn't slipped through. This could happen if a customer was using an old version of the Datadog.Trace NuGet package with a newer version of auto instrumentation. Note that this adds two additional framework references for .NET Core 3.1+, to check if we're on Windows. ## Test coverage Added an extra step to the manual instrumentation integration test to confirm we throw ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 👈 - #7722 - #7695 - #7723 - #7724

## Summary of changes Add a helper for comparing `ReadOnlyDictionary<>` instances ## Reason for change As part of the config work, we need to detect if tags have changed when customers do a manual/remote config update. This helper makes it easy ## Implementation details Added a `SequenceEqual` extension method. Note that I used `SequenceEqual` because it _already_ exists in _System.Linq_, but I could see an argument that it's too easy to use the wrong one, and instead we could use a different name? `IsSameAs(other)`? Also, I only wrote this for `ReadOnlyDictionary<>` because that's all we need, it's what we use for all our setting dictionaries, and it will be (a tiny bit) faster than making it `IDictionary<>`, but happy to change if people feel strongly. ## Test coverage Added unit tests ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 👈 - #7695 - #7723 - #7724 --------- Co-authored-by: Steven Bouwkamp <[email protected]>

…ttings (#7695) ## Summary of changes - Introduces `SettingsManager` responsible for managing `MutableSettings` and `ExporterSettings` ## Reason for change We need to be notified about runtime changes to settings (i.e. config in code or remote config) but don't want to tear down the world and rebuild every time. `SettingsManager` is responsible for handling this. Consumers subscribe to changes and can be notified about updates. This is a first step which just introduces the type, but doesn't force users to consume changes or remove the current places settings are exposed. Instead, it just encapsulates the changes. ## Implementation details - Introduce `SettingsManager` - Move code duplicated in `DynamicConfigurationManager` and `ConfigureIntegration` into `SettingsManager` - Create a new instance of `SettingsManager` (and maintain it throughout the app lifetime) - Subscribe to changes one time in `TracerManager` to do the "full rebuild" - This is a stop gap before we use it "properly" and stop exposing the settings on `TracerSettings` ## Test coverage - Mostly a refactor so covered by integration tests - Unit tests for `SettingsManager` functionality ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 - #7695 👈 - #7723 - #7724 - #7796 --------- Co-authored-by: Lucas Pimentel <[email protected]>

…7723) ## Summary of changes Instead of exposing settings like `ServiceVerion` and `Environment` on `TracerSettings`, only expose them on `MutableSettings` ## Reason for change This is all part of the refactoring towards having `TracerSettings` being an immutable settings object, that's created once on app startup, and fixed for the lifetime. `ServiceVerion` and `Environment` currently delegate to the `MutableSettings` object stored on `TracerSettings`, but are going to move that elsewhere shortly so that consumers can subscribe to changes ## Implementation details For this PR, it's just a case of changing `TracerSettings.XXX` => `TracerSettings.Mutable.XXX`. A future PR will then subsequently "fix" these usages properly. This is just a small step to be able to remove the mutable properties from `TracerSettings` ## Test coverage Just a refactoring, covered by existing tests. ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 - #7695 - #7723 👈 - #7724 - #7796

… config changes (#7796) ## Summary of changes A fix for #7724 to handle telemetry reporting in dynamic config "reset" scenarios ## Reason for change The system tests for #7724 were failing in some dynamic configuration scenarios. Specifically, the tests were sending remote config _without_ any configuration values "i.e. 'reset to use defaults'" and were waiting a telemetry update. However, we never sent it, because there was "no telemetry to record". Note that we _did_ correctly apply the new configuration, we just didn't report the telemetry correctly, primarily due to limitations in the telemetry protocol. This PR adds a fix for that, and will be merged into #7724. ## Implementation details The solution is to "remember" the telemetry from the default mutable configuration values, _without_ any dynamic sources, and "replay" this telemetry when we update telemetry. This feels kind of hacky, but it's something I suspected we might need to do, and had been avoiding up to this point because we do a "full reconfigure" anyway. ## Test coverage Added a specific unit test that mimics the behaviour of the system-test (i.e. an "empty" dynamic config response) and confirms the telemetry is recorded as expected ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 - #7695 - #7723 - #7724 - #7796 👈 Unlike other PRs in the stack, I'll merge this directly into #7724 to fix the tests there, just thought I'd keep this separate for easier reviewing

…building (#7724) ## Summary of changes - This is the big one - Update services to dynamically update when mutable settings or exporter settings change - Stop rebuilding everything when there's manual/remote configuration ## Reason for change This is the "endpoint" that we've been heading for - services only being disposed/rebuilt at the end of the app, and otherwise only rebuilding the _necessary_ parts. For example - we don't need to tear down all the API factories when a customer changes a global tag via remote config; they only need to change if the `ExporterSettings` change. The hope is that overall this reduces the overhead of using configuration in code and/or remote configuration, while also reducing the number of issues due to managing disposal of services. ## Implementation details Overall, this PR is kind of a pain. Moving from the "rebuild everything" to "reconfigure each service" couldn't be done piecemeal, so this is the one-shot PR. What's more, different services need different patterns (though we can probably consolidate some of them, this has taken a _lot_ of work and I likely changed patterns unnecessarily in some places). In general, there's a couple of patterns: - CI Vis doesn't let you change settings at runtime, so it _never_ needs to respond to changes. It always just uses the "initial" settings - Debugger _today_ doesn't respond to changes at runtime (except its own dynamic config), so for now we ignore Debugger too as it's not really a regression. I hope we can fix this soon though. - I've introduced the concept of `Managed*` versions of some services - These services generally "wrap" the existing type, delegating access to the underlying service, and handling settings changes - Many services only care about a sub-set of mutable settings, so they only update if they need to - Somewhat annoyingly, setting updates occur on a background thread, so we need to be careful about thread safety. Where necessary (most places) I've made sure access to a now-mutable service is done using `Volatile.Read()` (to ensure changes are visible) and are generally cached to a local variable (as the underlying field may be updated in the background). ## Test coverage In the vast majority of places, this should be covered by existing tests I plan to add some additional integration tests around reconfiguring and a bunch of manual testing to make sure I'm confident. ## Other details I strongly recommend reviewing commit-by-commit. They're generally self-contained, and hopefully simple enough to understand one commit at a time. https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 - #7695 - #7723 - #7724 👈 - #7796 This isn't the final PR in the stack, as there will be a bunch of cleaning up to do, but it's the final "implementation" PR

## Summary of changes Updates a couple of places where we're calling `Tracer.Instance` where we don't need to ## Reason for change In one of my other PRs I accidentally broke something that should _only_ have affected integration tests, but a bunch of unit tests broke. It highlighted where they were using `Tracer.Instance` and setting the global tracer for tests. In other places, it revealed that code that tests that _looked_ independent of other tests really wasn't... Calling `Tracer.Instance` potentially does a _lot_ of work, as it initializes the tracer. It's also hard to follow if we're making static calls out in places we don't need to. So just pass through the settings we want instead. ## Implementation details Instead of calling `Tracer.Instance.Settings`, use the value of `Tracer` or `TracerSettings` that's already available wherever possible. It makes the tests cleaner too. ## Test coverage Same coverage, just a bit cleaner ## Other details Included as part of the config stack, just because I already refactored some of this code, and can't be bothered to faff with merge conflicts: https://datadoghq.atlassian.net/browse/LANGPLAT-819 - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 - #7695 - #7723 - #7724 - #7744 👈

andrewlock added area:tracer The core tracer library (Datadog.Trace, does not include OpenTracing, native code, or integrations) type:cleanup Minor code clean up labels Sep 18, 2025

andrewlock requested review from a team as code owners September 18, 2025 12:34

This was referenced Sep 18, 2025

Move DefaultServiceName to MutableSettings #7530

Merged

Rebuild MutableSettings on dynamic config changes #7525

Merged

Extract MutableSettings from TracerSettings #7522

Merged

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from bff634b to 501ab05 Compare September 18, 2025 13:01

andrewlock requested review from a team as code owners September 18, 2025 13:01

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 5a6c43c to 18a7270 Compare September 18, 2025 13:01

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from 501ab05 to 74067a5 Compare September 18, 2025 14:04

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 18a7270 to 12dfa73 Compare September 18, 2025 14:04

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from 74067a5 to b7463f2 Compare September 19, 2025 10:22

andrewlock requested a review from a team as a code owner September 19, 2025 10:22

andrewlock requested review from anna-git and removed request for a team September 19, 2025 10:22

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 12dfa73 to e4a1dbb Compare September 19, 2025 10:22

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from b7463f2 to 83b1b8c Compare September 19, 2025 14:06

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from e4a1dbb to f62f8b4 Compare September 19, 2025 14:06

lucaspimentel approved these changes Sep 19, 2025

View reviewed changes

dudikeleti approved these changes Sep 22, 2025

View reviewed changes

This was referenced Sep 22, 2025

Fix ad-hoc use of TracerSettings to use MutableSettings where appropriate #7543

Merged

Fix calls to IsIntegrationEnabled(), IsErrorStatusCode(), and GetIntegrationAnalyticsSampleRate() #7544

Merged

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 41bca93 to 9cb26d0 Compare October 15, 2025 07:32

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from b55734f to ea05552 Compare October 15, 2025 09:56

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 9cb26d0 to 99df246 Compare October 15, 2025 09:56

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from ea05552 to 6a90f09 Compare October 15, 2025 12:22

andrewlock force-pushed the andrew/settings/3c-move-default-service-name branch from 99df246 to 388a390 Compare October 15, 2025 12:22

Base automatically changed from andrew/settings/3c-move-default-service-name to master October 15, 2025 15:11

Cleanup of PerTraceSettings.GetServiceName()

7655779

andrewlock force-pushed the andrew/settings/3d-simplify-per-trace-settings branch from 6a90f09 to 7655779 Compare October 15, 2025 15:12

andrewlock merged commit 1f8906c into master Oct 16, 2025
154 checks passed

andrewlock deleted the andrew/settings/3d-simplify-per-trace-settings branch October 16, 2025 08:59

github-actions bot added this to the vNext-v3 milestone Oct 16, 2025

andrewlock mentioned this pull request Oct 22, 2025

Create SettingsManager for managing mutable settings and ExporterSettings #7695

Merged

andrewlock mentioned this pull request Nov 10, 2025

Add fix for not re-reporting telemetry when there are "empty" dynamic config changes #7796

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Simplify `PerTraceSettings.GetServiceName()` #7532

Simplify `PerTraceSettings.GetServiceName()` #7532

Uh oh!

andrewlock commented Sep 18, 2025 •

edited

Loading

Uh oh!

datadog-official bot commented Sep 18, 2025 •

edited by datadog-datadog-prod-us1 bot

Loading

Uh oh!

dd-trace-dotnet-ci-bot bot commented Sep 18, 2025 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Simplify PerTraceSettings.GetServiceName() #7532

Simplify PerTraceSettings.GetServiceName() #7532

Uh oh!

Conversation

andrewlock commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of changes

Reason for change

Implementation details

Test coverage

Other details

Uh oh!

datadog-official bot commented Sep 18, 2025 • edited by datadog-datadog-prod-us1 bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Warnings

ℹ️ Info

Uh oh!

dd-trace-dotnet-ci-bot bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Execution-Time Benchmarks Report ⏱️

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Simplify `PerTraceSettings.GetServiceName()` #7532

Simplify `PerTraceSettings.GetServiceName()` #7532

andrewlock commented Sep 18, 2025 •

edited

Loading

datadog-official bot commented Sep 18, 2025 •

edited by datadog-datadog-prod-us1 bot

Loading

dd-trace-dotnet-ci-bot bot commented Sep 18, 2025 •

edited

Loading