Fix broken parenting when Ocelot API Gateway is used by bouwkast · Pull Request #8128 · DataDog/dd-trace-dotnet

bouwkast · 2026-02-02T14:56:04Z

Mostly generated by claude with a lot of handholding

Summary of changes

Add auto-instrumentation for Ocelot API gateway to fix broken distributed traces when Ocelot is used with DD_TRACE_OTEL_ENABLED and OpenTelemetry.Instrumentation.Http is used.

Reason for change

When customers use Ocelot v23.0.0+ alongside the OpenTelemetry.Instrumentation.Http NuGet package, distributed traces break. Ocelot creates a SocketsHttpHandler with a default ActivityHeadersPropagator (this is normal behavior), which causes DiagnosticsHandler to be added to the handler chain. When the OpenTelemetry HTTP instrumentation is registered, it subscribes to the DiagnosticSource events from DiagnosticsHandler and injects its own trace context headers into downstream requests which overwrites the x-datadog-* / W3C traceparent headers already set by our HttpClient instrumentation.

Without the OpenTelemetry HTTP instrumentation NuGet installed, the DiagnosticsHandler Activity events have no subscriber to inject competing headers, so the issue does not occur.

For customers this results in broken parenting for traces/spans.

Implementation details

OcelotMessageInvokerPoolIntegration: Instruments Ocelot.Requester.MessageInvokerPool.CreateHandler to set ActivityHeadersPropagator = null on the returned SocketsHttpHandler, preventing DiagnosticsHandler from being added to the handler chain.
- Two [InstrumentMethod] attributes handle the return type change between versions:
  - v23.0.0–24.0.*: returns HttpMessageHandler
  - v24.1.0–24..: returns SocketsHttpHandler

Note: YARP needs to be updated as well from CreateNoOutputPropagator() to null I'll do this in a follow up

Test coverage

Added a sample application Samples.Ocelot.DistributedTracing that has Ocelot configured as a reverse proxy and OpenTelemetry.Instrumentation.Http installed and setup. Note that not having OpenTelemetry.Instrumentation.Http causes it to not re-produce.
Tests are added in OcelotDistributedTracingTests which follow the same pattern as the YARP tests
Added snapshot, note that there are a couple of commits here where I removed the fix, saved the snapshot (broken) and then re-ran the snapshots. This is just to showcase the before/after

Other details

Supported Ocelot versions: 23.0.0 to 24.*
Earlier versions do not have the same behavior as HttpMessageHandler was introduced first in 23 and then changed to SocketsHttpHandler in 24.

pr-commenter · 2026-02-02T15:37:01Z

Benchmarks

Benchmark execution time: 2026-03-27 18:49:03

Comparing candidate commit 3a108a5 in PR branch steven/ocelot-instrumentation with baseline commit 017e910 in branch master.

Found 4 performance improvements and 4 performance regressions! Performance is the same for 261 metrics, 19 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

🟥 execution_time [+88.060ms; +88.168ms] or [+79.082%; +79.179%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net6.0

🟩 execution_time [-14.337ms; -13.394ms] or [-6.695%; -6.255%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody netcoreapp3.1

🟥 execution_time [+13.211ms; +19.517ms] or [+6.565%; +9.698%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net472

🟩 execution_time [-16.384ms; -11.782ms] or [-7.270%; -5.228%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

🟩 execution_time [-13.823ms; -10.199ms] or [-8.983%; -6.628%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1

🟥 execution_time [+146.702µs; +151.858µs] or [+5.224%; +5.408%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark netcoreapp3.1

🟥 allocated_mem [+17.914KB; +17.937KB] or [+7.036%; +7.045%]

scenario:Benchmarks.Trace.NLogBenchmark.EnrichedLog net472

🟩 throughput [+7328.493op/s; +8138.238op/s] or [+5.658%; +6.283%]

dd-trace-dotnet-ci-bot · 2026-02-02T15:52:02Z

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing This PR (8128) and master.

✅ No regressions detected - check the details below

Full Metrics Comparison

FakeDbCommand

Metric	Master (Mean ± 95% CI)	Current (Mean ± 95% CI)	Change	Status
.NET Framework 4.8 - Baseline
duration	72.27 ± (72.40 - 72.79) ms	75.54 ± (75.50 - 75.84) ms	+4.5%	✅⬆️
.NET Framework 4.8 - Bailout
duration	76.16 ± (76.05 - 76.40) ms	80.12 ± (80.17 - 80.65) ms	+5.2%	✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration	1095.57 ± (1093.81 - 1101.85) ms	1106.36 ± (1106.20 - 1112.05) ms	+1.0%	✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms	23.13 ± (23.07 - 23.19) ms	23.03 ± (22.99 - 23.07) ms	-0.4%	✅
process.time_to_main_ms	88.89 ± (88.69 - 89.09) ms	87.77 ± (87.53 - 88.00) ms	-1.3%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.91 ± (10.91 - 10.92) MB	10.90 ± (10.89 - 10.90) MB	-0.1%	✅
runtime.dotnet.threads.count	12 ± (12 - 12)	12 ± (12 - 12)	+0.0%	✅
.NET Core 3.1 - Bailout
process.internal_duration_ms	23.14 ± (23.09 - 23.19) ms	22.93 ± (22.88 - 22.97) ms	-0.9%	✅
process.time_to_main_ms	90.36 ± (90.14 - 90.59) ms	88.72 ± (88.50 - 88.95) ms	-1.8%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.95 ± (10.95 - 10.96) MB	10.94 ± (10.93 - 10.94) MB	-0.2%	✅
runtime.dotnet.threads.count	13 ± (13 - 13)	13 ± (13 - 13)	+0.0%	✅
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms	235.16 ± (234.14 - 236.17) ms	229.96 ± (228.86 - 231.06) ms	-2.2%	✅
process.time_to_main_ms	544.41 ± (543.08 - 545.73) ms	536.01 ± (534.75 - 537.26) ms	-1.5%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	47.82 ± (47.79 - 47.84) MB	47.88 ± (47.85 - 47.91) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	28 ± (28 - 29)	28 ± (28 - 28)	-0.9%	✅
.NET 6 - Baseline
process.internal_duration_ms	22.05 ± (22.00 - 22.10) ms	21.85 ± (21.80 - 21.90) ms	-0.9%	✅
process.time_to_main_ms	77.56 ± (77.35 - 77.76) ms	76.39 ± (76.18 - 76.59) ms	-1.5%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.63 ± (10.63 - 10.63) MB	10.62 ± (10.62 - 10.62) MB	-0.1%	✅
runtime.dotnet.threads.count	10 ± (10 - 10)	10 ± (10 - 10)	+0.0%	✅
.NET 6 - Bailout
process.internal_duration_ms	21.90 ± (21.84 - 21.95) ms	21.67 ± (21.62 - 21.72) ms	-1.0%	✅
process.time_to_main_ms	78.38 ± (78.20 - 78.55) ms	77.37 ± (77.16 - 77.58) ms	-1.3%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	10.70 ± (10.69 - 10.71) MB	10.73 ± (10.72 - 10.73) MB	+0.3%	✅⬆️
runtime.dotnet.threads.count	11 ± (11 - 11)	11 ± (11 - 11)	+0.0%	✅
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms	385.09 ± (382.71 - 387.47) ms	387.44 ± (385.22 - 389.66) ms	+0.6%	✅⬆️
process.time_to_main_ms	540.26 ± (539.26 - 541.27) ms	537.87 ± (536.83 - 538.92) ms	-0.4%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	49.84 ± (49.81 - 49.87) MB	50.03 ± (50.00 - 50.06) MB	+0.4%	✅⬆️
runtime.dotnet.threads.count	28 ± (28 - 28)	28 ± (28 - 28)	+0.0%	✅⬆️
.NET 8 - Baseline
process.internal_duration_ms	20.03 ± (19.98 - 20.08) ms	20.02 ± (19.97 - 20.06) ms	-0.1%	✅
process.time_to_main_ms	75.92 ± (75.75 - 76.08) ms	75.85 ± (75.69 - 76.02) ms	-0.1%	✅
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	7.66 ± (7.66 - 7.66) MB	7.67 ± (7.66 - 7.68) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	10 ± (10 - 10)	10 ± (10 - 10)	+0.0%	✅
.NET 8 - Bailout
process.internal_duration_ms	19.96 ± (19.91 - 20.01) ms	20.14 ± (20.09 - 20.18) ms	+0.9%	✅⬆️
process.time_to_main_ms	76.96 ± (76.75 - 77.17) ms	77.30 ± (77.10 - 77.49) ms	+0.4%	✅⬆️
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	7.73 ± (7.72 - 7.74) MB	7.74 ± (7.73 - 7.75) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	11 ± (11 - 11)	11 ± (11 - 11)	+0.0%	✅
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms	304.59 ± (302.32 - 306.85) ms	309.48 ± (306.97 - 311.98) ms	+1.6%	✅⬆️
process.time_to_main_ms	499.98 ± (499.16 - 500.79) ms	500.64 ± (499.80 - 501.48) ms	+0.1%	✅⬆️
runtime.dotnet.exceptions.count	0 ± (0 - 0)	0 ± (0 - 0)	+0.0%	✅
runtime.dotnet.mem.committed	37.10 ± (37.07 - 37.13) MB	37.07 ± (37.05 - 37.10) MB	-0.1%	✅
runtime.dotnet.threads.count	27 ± (27 - 27)	27 ± (27 - 27)	-0.7%	✅

HttpMessageHandler

Metric	Master (Mean ± 95% CI)	Current (Mean ± 95% CI)	Change	Status
.NET Framework 4.8 - Baseline
duration	213.57 ± (213.09 - 214.03) ms	213.41 ± (213.31 - 214.20) ms	-0.1%	✅
.NET Framework 4.8 - Bailout
duration	217.56 ± (217.20 - 218.23) ms	218.72 ± (218.16 - 219.30) ms	+0.5%	✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration	1219.98 ± (1221.50 - 1229.71) ms	1247.95 ± (1248.38 - 1257.02) ms	+2.3%	✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms	203.57 ± (203.06 - 204.08) ms	211.26 ± (210.77 - 211.74) ms	+3.8%	✅⬆️
process.time_to_main_ms	88.68 ± (88.44 - 88.91) ms	92.54 ± (92.20 - 92.88) ms	+4.4%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	15.96 ± (15.94 - 15.97) MB	15.96 ± (15.94 - 15.98) MB	+0.0%	✅⬆️
runtime.dotnet.threads.count	20 ± (20 - 20)	20 ± (20 - 20)	+0.3%	✅⬆️
.NET Core 3.1 - Bailout
process.internal_duration_ms	203.96 ± (203.44 - 204.47) ms	210.84 ± (210.28 - 211.41) ms	+3.4%	✅⬆️
process.time_to_main_ms	89.58 ± (89.38 - 89.78) ms	93.70 ± (93.36 - 94.04) ms	+4.6%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	15.99 ± (15.96 - 16.01) MB	15.92 ± (15.90 - 15.94) MB	-0.4%	✅
runtime.dotnet.threads.count	21 ± (21 - 21)	21 ± (21 - 21)	+0.8%	✅⬆️
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms	414.12 ± (412.70 - 415.54) ms	424.06 ± (422.59 - 425.52) ms	+2.4%	✅⬆️
process.time_to_main_ms	544.31 ± (542.89 - 545.73) ms	555.44 ± (553.94 - 556.94) ms	+2.0%	✅⬆️
runtime.dotnet.exceptions.count	3 ± (3 - 3)	3 ± (3 - 3)	+0.0%	✅
runtime.dotnet.mem.committed	58.67 ± (58.63 - 58.72) MB	58.75 ± (58.71 - 58.80) MB	+0.1%	✅⬆️
runtime.dotnet.threads.count	30 ± (30 - 30)	30 ± (30 - 30)	+0.7%	✅⬆️
.NET 6 - Baseline
process.internal_duration_ms	207.51 ± (206.97 - 208.05) ms	215.82 ± (215.29 - 216.35) ms	+4.0%	✅⬆️
process.time_to_main_ms	76.54 ± (76.30 - 76.78) ms	80.28 ± (80.03 - 80.53) ms	+4.9%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	16.23 ± (16.21 - 16.26) MB	16.18 ± (16.16 - 16.20) MB	-0.4%	✅
runtime.dotnet.threads.count	19 ± (19 - 19)	20 ± (19 - 20)	+0.9%	✅⬆️
.NET 6 - Bailout
process.internal_duration_ms	205.34 ± (204.82 - 205.85) ms	215.23 ± (214.65 - 215.81) ms	+4.8%	✅⬆️
process.time_to_main_ms	77.17 ± (76.95 - 77.38) ms	81.50 ± (81.26 - 81.75) ms	+5.6%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	16.28 ± (16.26 - 16.31) MB	16.20 ± (16.17 - 16.23) MB	-0.5%	✅
runtime.dotnet.threads.count	20 ± (20 - 20)	20 ± (20 - 21)	+1.7%	✅⬆️
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms	599.33 ± (596.69 - 601.97) ms	600.47 ± (598.12 - 602.81) ms	+0.2%	✅⬆️
process.time_to_main_ms	548.76 ± (547.58 - 549.94) ms	561.02 ± (559.60 - 562.43) ms	+2.2%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	61.38 ± (61.28 - 61.47) MB	61.24 ± (61.14 - 61.34) MB	-0.2%	✅
runtime.dotnet.threads.count	31 ± (31 - 31)	31 ± (31 - 31)	+0.3%	✅⬆️
.NET 8 - Baseline
process.internal_duration_ms	209.35 ± (208.84 - 209.86) ms	214.35 ± (213.83 - 214.87) ms	+2.4%	✅⬆️
process.time_to_main_ms	77.68 ± (77.42 - 77.95) ms	79.57 ± (79.26 - 79.87) ms	+2.4%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	11.61 ± (11.60 - 11.63) MB	11.57 ± (11.55 - 11.59) MB	-0.4%	✅
runtime.dotnet.threads.count	19 ± (19 - 19)	19 ± (19 - 19)	+0.8%	✅⬆️
.NET 8 - Bailout
process.internal_duration_ms	207.94 ± (207.39 - 208.49) ms	214.28 ± (213.72 - 214.85) ms	+3.0%	✅⬆️
process.time_to_main_ms	78.42 ± (78.13 - 78.71) ms	80.74 ± (80.51 - 80.97) ms	+3.0%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	11.69 ± (11.67 - 11.71) MB	11.63 ± (11.61 - 11.65) MB	-0.5%	✅
runtime.dotnet.threads.count	20 ± (20 - 20)	20 ± (20 - 20)	+1.7%	✅⬆️
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms	536.46 ± (530.34 - 542.57) ms	555.51 ± (547.59 - 563.42) ms	+3.6%	✅⬆️
process.time_to_main_ms	508.23 ± (507.17 - 509.29) ms	518.21 ± (517.01 - 519.42) ms	+2.0%	✅⬆️
runtime.dotnet.exceptions.count	4 ± (4 - 4)	4 ± (4 - 4)	+0.0%	✅
runtime.dotnet.mem.committed	50.77 ± (50.69 - 50.85) MB	51.03 ± (50.93 - 51.12) MB	+0.5%	✅⬆️
runtime.dotnet.threads.count	30 ± (30 - 30)	30 ± (30 - 30)	-0.1%	✅

Comparison explanation

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 highlighted 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).

Duration charts

FakeDbCommand (.NET Framework 4.8)

gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (76ms)  : 73, 78
    master - mean (73ms)  : 70, 76

    section Bailout
    This PR (8128) - mean (80ms)  : 77, 84
    master - mean (76ms)  : 75, 78

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (1,109ms)  : 1067, 1151
    master - mean (1,098ms)  : 1039, 1157

FakeDbCommand (.NET Core 3.1)

gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (118ms)  : 113, 124
    master - mean (119ms)  : 116, 123

    section Bailout
    This PR (8128) - mean (119ms)  : 114, 124
    master - mean (121ms)  : 117, 125

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (803ms)  : 783, 822
    master - mean (818ms)  : 795, 841

FakeDbCommand (.NET 6)

gantt
    title Execution time (ms) FakeDbCommand (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (105ms)  : 101, 109
    master - mean (106ms)  : 103, 110

    section Bailout
    This PR (8128) - mean (106ms)  : 103, 108
    master - mean (107ms)  : 105, 109

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (954ms)  : 923, 986
    master - mean (956ms)  : 918, 993

FakeDbCommand (.NET 8)

gantt
    title Execution time (ms) FakeDbCommand (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (104ms)  : 100, 108
    master - mean (104ms)  : 101, 107

    section Bailout
    This PR (8128) - mean (105ms)  : 102, 109
    master - mean (105ms)  : 103, 107

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (841ms)  : 805, 877
    master - mean (836ms)  : 801, 870

HttpMessageHandler (.NET Framework 4.8)

gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (214ms)  : 209, 219
    master - mean (214ms)  : 207, 220

    section Bailout
    This PR (8128) - mean (219ms)  : 213, 225
    master - mean (218ms)  : 212, 223

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (1,253ms)  : 1188, 1318
    master - mean (1,226ms)  : 1164, 1287

HttpMessageHandler (.NET Core 3.1)

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (313ms)  : 306, 321
    master - mean (302ms)  : 293, 311

    section Bailout
    This PR (8128) - mean (314ms)  : 307, 322
    master - mean (303ms)  : 297, 309

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (1,022ms)  : 997, 1046
    master - mean (999ms)  : 974, 1024

HttpMessageHandler (.NET 6)

gantt
    title Execution time (ms) HttpMessageHandler (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (305ms)  : 296, 314
    master - mean (293ms)  : 285, 301

    section Bailout
    This PR (8128) - mean (306ms)  : 300, 313
    master - mean (291ms)  : 284, 299

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (1,193ms)  : 1157, 1228
    master - mean (1,179ms)  : 1140, 1219

HttpMessageHandler (.NET 8)

gantt
    title Execution time (ms) HttpMessageHandler (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8128) - mean (306ms)  : 299, 312
    master - mean (298ms)  : 290, 306

    section Bailout
    This PR (8128) - mean (306ms)  : 299, 313
    master - mean (297ms)  : 291, 304

    section CallTarget+Inlining+NGEN
    This PR (8128) - mean (1,117ms)  : 983, 1252
    master - mean (1,080ms)  : 994, 1166

andrewlock · 2026-03-19T07:37:37Z

Earlier versions do not have the same behavior as HttpMessageHandler was introduced first in 23 and then changed to SocketsHttpHandler in 24

So just to confirm, the original issue doesn't repro on earlier versions?

andrewlock

LGTM, just a couple of minor things:

We generally try to cover the full range of supported TFMs, so we should probably support .NET 6+ as Ocelot does
Should this be the HttpMessageHandler or a new Ocelot integration?
Couple of nits (using the more compact aspnetcore setup, using combinatorial data attr etc for future)

tracer/build/PackageVersionsGeneratorDefinitions.json

tracer/build/supported_versions.json

andrewlock · 2026-03-19T07:45:19Z

...utoInstrumentation/Http/HttpClient/SocketsHttpHandler/OcelotMessageInvokerPoolIntegration.cs

+[EditorBrowsable(EditorBrowsableState.Never)]
+public sealed class OcelotMessageInvokerPoolIntegration
+{
+    private const string IntegrationName = nameof(Configuration.IntegrationId.HttpMessageHandler);


Should this be a new integration, Ocelot, instead of HttpMessageHandler? 🤔 I'm undecided tbh, I get the reasoning.

Yeah, this initially was Ocelot but Yarp went with HttpMessageHandler so I just forced Claude to follow that

Honestly I'm not sure what is ideal

I could probably go both ways, but we aren't really "instrumenting" YARP/Ocelot here (YARP uses HttpMessageHandler as well).

I think based on that and that we are essentially attempting to fix re-parenting issues here not calling it Ocelot is the better representation, but I would say that if for some reason someone needs to disable this re-parenting fix I guess they would ideally want the option to do that without having to disable all of the HttpMessageHandler instrumentation.

Maybe a second PR to update both YARP and this to be controlled by either HttpMessageHandler or their integration name itself?

tracer/test/Datadog.Trace.ClrProfiler.IntegrationTests/OcelotDistributedTracingTests.cs

...ions/integrations/Samples.Ocelot.DistributedTracing/Samples.Ocelot.DistributedTracing.csproj

tracer/test/test-applications/integrations/Samples.Ocelot.DistributedTracing/Program.cs

bouwkast · 2026-03-24T15:29:02Z

So just to confirm, the original issue doesn't repro on earlier versions?

Correct I couldn't get it to reproduce in earlier versions

lucaspimentel · 2026-03-30T19:13:49Z

@codex review

chatgpt-codex-connector · 2026-03-30T19:22:18Z

Codex Review: Didn't find any major issues. 🎉

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

This resolves a reparenting issue when OpenTelemetry.Instrumentation.Http is present and running.

This demonstrates the difference in parenting when we have Ocelot and OpenTelemetry compared to when we have the instrumenation that gets rid of the parenting misconfiguration. Note that in this snapshot there is an "ID_3" referenced as the "ParentId", but that there is no "ID_3" present in the snapshot.

Just doing to this help with reviewers to see what changed / what it should be

Cover Ocelot 23.x which supports net6.0-net8.0, not just net8.0+.

bouwkast added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label Feb 2, 2026

bouwkast force-pushed the steven/ocelot-instrumentation branch from ae314c0 to 88228c0 Compare February 4, 2026 22:28

bouwkast force-pushed the steven/ocelot-instrumentation branch from b9bec75 to 1547cf8 Compare March 9, 2026 18:25

bouwkast force-pushed the steven/ocelot-instrumentation branch from 1547cf8 to 7d03568 Compare March 16, 2026 19:46

bouwkast changed the title ~~Add Ocelot auto-instrumentation~~ Add Ocelot API gateway auto-instrumentation Mar 16, 2026

bouwkast force-pushed the steven/ocelot-instrumentation branch 2 times, most recently from 2340187 to 6aaa0a6 Compare March 17, 2026 15:31

bouwkast added type:bug area:automatic-instrumentation Automatic instrumentation managed C# code (Datadog.Trace.ClrProfiler.Managed) identified-by:customer labels Mar 17, 2026

bouwkast force-pushed the steven/ocelot-instrumentation branch from 6aaa0a6 to 1ab66fb Compare March 17, 2026 17:49

bouwkast mentioned this pull request Mar 17, 2026

Fix Yarp reparenting if OpenTelemetry.Instrumentation.Http is present #8321

Draft

bouwkast force-pushed the steven/ocelot-instrumentation branch from 1ab66fb to 334375f Compare March 18, 2026 14:35

bouwkast marked this pull request as ready for review March 18, 2026 18:55

bouwkast requested review from a team as code owners March 18, 2026 18:55

andrewlock reviewed Mar 19, 2026

View reviewed changes

andrewlock approved these changes Mar 19, 2026

View reviewed changes

bouwkast changed the title ~~Add Ocelot API gateway auto-instrumentation~~ Fix broken parenting when Ocelot API Gateway is used Mar 19, 2026

bouwkast force-pushed the steven/ocelot-instrumentation branch from 5cd33a5 to 566fef8 Compare March 20, 2026 13:10

bouwkast force-pushed the steven/ocelot-instrumentation branch from ce38e3e to 780e797 Compare March 24, 2026 15:50

bouwkast added 2 commits April 2, 2026 10:49

Add Ocelot auto-instrumentation

c7a6c83

This resolves a reparenting issue when OpenTelemetry.Instrumentation.Http is present and running.

bouwkast added 11 commits April 2, 2026 10:49

Update snapshot with correct parenting

8f0953f

Just doing to this help with reviewers to see what changed / what it should be

Update snapshot with new _dd.svc_src

8343c4f

Widen Ocelot test to NET6_0_OR_GREATER

c99866c

Cover Ocelot 23.x which supports net6.0-net8.0, not just net8.0+.

Use CombinatorialOrPairwiseData for Ocelot test

38ef900

Remove redundant assertions covered by snapshot

fba7ce3

Fix the supported .NET versions

4fdf812

Rewrite Ocelot sample to modern minimal hosting

1538919

Fix generated_calltargets

0a1b210

Re-run the GeneratePackageVersions

288e7ac

Update generated_calltargets

0b218b9

Fix generated_calltargets

ae9d877

bouwkast force-pushed the steven/ocelot-instrumentation branch from 3a108a5 to ae9d877 Compare April 2, 2026 14:54

Conversation

bouwkast commented Feb 2, 2026 • 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!

pr-commenter bot commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Explanation

More details about the CI and significant changes

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net6.0

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody netcoreapp3.1

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net472

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark netcoreapp3.1

scenario:Benchmarks.Trace.NLogBenchmark.EnrichedLog net472

Uh oh!

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

Uh oh!

Execution-Time Benchmarks Report ⏱️

FakeDbCommand

HttpMessageHandler

Uh oh!

andrewlock commented Mar 19, 2026

Uh oh!

andrewlock left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

andrewlock Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

bouwkast Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

bouwkast Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bouwkast commented Mar 24, 2026

Uh oh!

lucaspimentel commented Mar 30, 2026

Uh oh!

chatgpt-codex-connector bot commented Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bouwkast commented Feb 2, 2026 •

edited

Loading

pr-commenter bot commented Feb 2, 2026 •

edited

Loading

dd-trace-dotnet-ci-bot bot commented Feb 2, 2026 •

edited

Loading