chore: backport multiple PRs to release-v2.10.x - #5174
Merged
darccio merged 18 commits intoAug 10, 2026
Conversation
<!-- * New contributors are highly encouraged to read our [CONTRIBUTING](/CONTRIBUTING.md) documentation. * Commit and PR titles should be prefixed with the general area of the pull request's change. --> No longer includes decoding code in benchmarks, making measurements more accurate to what we actually care about (encoding payloads). Partially or fully reverts the regressions from this [PR](#4849). <!-- * A brief description of the change being made with this pull request. * If the description here cannot be expressed in a succinct form, consider opening multiple pull requests instead of a single one. --> Reduce memory overhead of ETP benchmarks AND make benchmarks more accurate to real life customer data. Decoding does not happen in a customer app, but rather in the backend/agent. Having decoding measured as part of a benchmark's life cycle is not realistic or usually helpful. <!-- * What inspired you to submit this pull request? * Link any related GitHub issues or PRs here. * If this resolves a GitHub issue, include "Fixes #XXXX" to link the issue and auto-close it on merge. --> <!-- * Authors can use this list as a reference to ensure that there are no problems during the review but the signing off is to be done by the reviewer(s). --> - [ ] Changed code has unit tests for its functionality at or near 100% coverage. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. - [ ] There is a benchmark for any new code, or changes to existing code. - [ ] If this interacts with the agent in a new way, a system test has been added. - [ ] New code is free of linting errors. You can check this by running `make lint` locally. - [ ] New code doesn't break existing tests. You can check this by running `make test` locally. - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [ ] All generated files are up to date. You can check this by running `make generate` locally. - [ ] Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally. Unsure? Have a question? Request a review! Co-authored-by: kemal.akkoyun <kemal.akkoyun@datadoghq.com> (cherry picked from commit d177e83)
…ractTextMap (#5119) ### What does this PR do? Optimizes `propagatorBaggage.extractTextMap` (`ddtrace/tracer/textmap.go`), which runs on every `Extract` call as part of the default propagator chain (`datadog,tracecontext,baggage`) — including the overwhelmingly common case where no `baggage` header is present. Two changes: 1. **Avoid the `ForeachKey` closure on the fast path.** `ForeachKey` is an interface method (`TextMapReader`), so escape analysis must assume any closure passed to it escapes — this forced both the closure and the local it captured onto the heap on *every* call. Added `lookupBaggageHeader`, which type-switches on `TextMapCarrier`/`HTTPHeadersCarrier` and iterates directly (no closure). Confirmed via `go build -gcflags=-m` that no heap escapes remain on this path. Other `TextMapReader` implementations still go through `ForeachKey`, isolated in its own function (`foreachBaggageHeader`) so its heap-boxed locals stay scoped to that fallback only. 2. **Return `(nil, nil)` instead of an allocated empty `*SpanContext`** when no baggage is found (or a malformed item forces a drop). `propagatorBaggage` is unexported and only reachable through `chainedPropagator`, whose two callers (`extractBaggage`, `extractIncomingSpanContext`) already nil-check the result — so this is a safe, narrower contract, not a behavior change for any caller. ### Motivation Measured with escape analysis and `pprof`, not assumed: `BenchmarkExtractBaggageNoHeaders` showed 3 allocs/op (288 B), with the closure pattern responsible for 2 of the 3 and the unconditional `*SpanContext` responsible for 86% of the bytes. In the default chain, baggage was actually the *most expensive* of the three extractors on the no-headers path despite doing the least work. ``` BenchmarkExtractBaggageNoHeaders-10 147.75 ns/op 288 B/op 3 allocs/op (before) BenchmarkExtractBaggageNoHeaders-10 18.09 ns/op 0 B/op 0 allocs/op (after) ``` `benchstat` over all `BenchmarkExtract*` benchmarks confirms every other extractor is noise-level unchanged. Also added: - `BenchmarkExtractBaggage` (`/TextMapCarrier` and `/HTTPHeadersCarrier`), since no existing benchmark exercised extraction with a baggage header actually present. - A baggage case in `TestExtractNoHeaders` and three subtests in `TestExtractHeaderNameCaseInsensitivity` covering non-canonical carrier keys and `http.Header` multi-value last-wins semantics — gaps surfaced during review that the new carrier-specific fast path made load-bearing. - Rewrote the doc comment on `BenchmarkExtractBaggageNoHeaders`, which asserted the old "a SpanContext must be allocated regardless" contract this PR removes. ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. - [x] There is a benchmark for any new code, or changes to existing code. - [ ] If this interacts with the agent in a new way, a system test has been added. - [x] New code is free of linting errors. Verified with `golangci-lint run ./ddtrace/tracer/...` (0 issues) and `checklocks.sh` (no new issues; two pre-existing suggestions are in untouched files). - [x] New code doesn't break existing tests. Full `ddtrace/tracer` suite passes with `-race`. - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [x] All generated files are up to date. - [ ] Non-trivial go.mod changes — N/A, no go.mod changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: kakkoyun <kakkoyun@users.noreply.github.com> Co-authored-by: dario.castane <dario.castane@datadoghq.com> (cherry picked from commit 39ceca0)
### What does this PR do? Three targeted fixes to the tracer's HTTP-header propagation layer (`ddtrace/tracer/textmap.go`), each in its own commit with dedicated tests: 1. **Percent-encode `ot-baggage-*` values on inject.** The legacy OpenTracing `ot-baggage-<key>` prefix path re-emitted baggage values verbatim. A baggage value containing a decoded control byte (e.g. from a percent-encoded CRLF) became a raw control byte on every outbound instrumented call, causing `net/http` to reject the request and letting non-validating carriers (gRPC metadata, custom `TextMapWriter`s) deliver it downstream. Now percent-encoded the same way `propagatorBaggage.injectTextMap` already encodes the W3C `baggage` header. 2. **Enforce baggage item/byte limits on `ot-baggage-*`.** The W3C `baggage` header is capped at 64 items / 8192 bytes, but the `ot-baggage-*` prefix path had no such limit on either extractor (Datadog or W3C) or the injector, so an attacker could smuggle an unbounded number of baggage entries. Added a shared `addOTBaggageItem` helper and capped the injector loop the same way `propagatorBaggage` already does. 3. **Bound `tracestate` header size on extract and inject.** Only the `dd=` list-member was size-checked (256 bytes); the full incoming `tracestate` header — including arbitrarily large non-Datadog vendor entries — was stored verbatim as a propagating tag and re-emitted on every outbound call and shipped to the Agent as span meta. Now the whole header is dropped on extract past 4096 bytes, and oversized non-dd members (over 512 bytes, per the W3C recommendation) are skipped when the header is rebuilt on inject. ### Motivation Hardening for the tracer's propagation layer against malformed/oversized header-based baggage and tracestate input from untrusted upstream callers. Each commit's tests assert the secure behavior directly (no control bytes survive re-injection, caps are enforced, oversized entries don't survive round-trip) at both the unit level (`ddtrace/tracer`) and end-to-end through the `net/http` and `gRPC` contrib integrations. ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. - [ ] There is a benchmark for any new code, or changes to existing code. - [ ] If this interacts with the agent in a new way, a system test has been added. - [x] New code is free of linting errors. You can check this by running `make lint` locally. - [x] New code doesn't break existing tests. You can check this by running `make test` locally. - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [ ] All generated files are up to date. You can check this by running `make generate` locally. - [ ] Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dario.castane <dario.castane@datadoghq.com> (cherry picked from commit 0553cf2)
…ocol (#5148) Third in a split of [#5122](#5122) into a reviewable stack (see that PR for the full sequence). Stacked on [#5147](#5147) — this PR's diff is scoped to just the change below; merge #5147 first. The name `TraceProtocol` read like "the protocol in use", but the value is only what was asked for — it says nothing about whether the trace-agent can actually serve it. Callers have to combine it with agent capability to get the protocol on the wire, and the old name gave no hint of that, which is how the gate in `newConfig` ended up being the only place that knew the difference. Renames to `RequestedTraceProtocol` and documents the distinction. No behaviour change: the OTLP-span-metrics override stays exactly as it was (removed later in this stack, in a sibling PR). Also adds `TraceProtocolVersionString`, the inverse of `resolveTraceProtocol`, and uses it in `SetTraceProtocol`. The env-var path reports `DD_TRACE_AGENT_PROTOCOL_VERSION` through the provider as the raw string (`"1.0"`), while the setter reported a `float64` — the same telemetry key arrived with two different types depending on which source set it last. - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [x] New code doesn't break existing tests. You can check this by running `make test` locally. - [x] New code is free of linting errors. You can check this by running `make lint` locally. - [x] All generated files are up to date. You can check this by running `make generate` locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dario.castane <dario.castane@datadoghq.com>
…5120) ### What does this PR do? Fixes `chainedPropagator.extractIncomingSpanContext` (`ddtrace/tracer/textmap.go`) so that baggage survives `DD_TRACE_PROPAGATION_EXTRACT_FIRST=true` regardless of extractor order or propagation behavior. **The bug:** with extract-first enabled, the extractor loop returned early on the first successful extractor (or on `ErrSpanContextNotFound`) — before the baggage propagator, later in the default chain (`datadog,tracecontext,baggage`), ever ran. This violated the tracer's own documented contract at `textmap.go:73-81` (*"continue (default): Continue the trace from incoming headers. Baggage is propagated."*) and produced three distinct failures depending on input: - Datadog trace headers + a `baggage` header → baggage silently dropped. - A `baggage` header only, no trace headers → returns `ErrSpanContextNotFound` instead of a baggage-only context (worse than dropping: this differs from non-extract-first behavior for identical input). - Style order `baggage,datadog` (baggage runs *first*) → baggage is extracted into `pendingBaggage` and then discarded by the early return, proving this isn't just "baggage never ran" — a fix confined to `Extract()`'s restart branch couldn't have caught this case. **The fix:** extract baggage once, up front, independent of extractor order and of `onlyExtractFirst` short-circuiting the trace-context loop, then let the existing tail logic (which already correctly merges `pendingBaggage`, builds a baggage-only context, or falls back to `ErrSpanContextNotFound`) run uniformly on every path. This removes the asymmetry entirely rather than adding a third special case. **Bonus fix found during review:** the `restart` branch's compensation (`baggage = p.extractBaggage(carrier)`) *replaced* `incomingCtx.baggage` instead of merging into it, silently dropping legacy `ot-baggage-*` items whenever `restart`+extract-first had no W3C `baggage` header. Simplifying that branch to just read `incomingCtx.baggage` (now always fully populated) fixes this too. **Also fixed:** the tail's `log.Debug("Extracted span context: %s", ctx.safeDebugString())` was unguarded, so `safeDebugString()` (an `fmt.Sprintf` over 8 args + an RLock) was evaluated on every successful extraction even with debug logging off — and extract-first requests now reach this line where they previously returned early. Guarded with `log.DebugEnabled()`, per the pattern documented on that function. Verified as a net improvement, not just cost-neutral: isolated benchmarks show `ExtractW3C`/`ExtractW3CUppercase` at -17% bytes / -24% allocs / -21% time, with no regressions elsewhere. ### Motivation Found via adversarial code review while working on a separate baggage-allocation PR. Reproduced through the public API only (`tracer.NewPropagator(nil)` + `Extract`), no internals: ``` === Scenario A: datadog trace headers + baggage, continue (default) === extractFirst=false -> baggage=map[user:alice] err=<nil> (before & after) extractFirst=true -> baggage=map[] err=<nil> (before, buggy) extractFirst=true -> baggage=map[user:alice] err=<nil> (after, fixed) === Scenario B: baggage header ONLY, continue (default) === extractFirst=false -> baggage=map[user:bob] err=<nil> (before & after) extractFirst=true -> baggage=map[] err=span context not found (before, buggy) extractFirst=true -> baggage=map[user:bob] err=<nil> (after, fixed) === Scenario C: style order 'baggage,datadog' === extractFirst=true -> baggage=map[] err=<nil> (before, buggy) extractFirst=true -> baggage=map[user:alice] err=<nil> (after, fixed) ``` ### Update: fixed a regression Codex found in this same PR [Codex left a review comment](#5120 (comment)) on the `break` this PR added for the `ExtractFirst` + `ErrSpanContextNotFound` case: with the default `datadog,tracecontext,baggage` order, a request with a valid W3C `traceparent` + a `baggage` header but no `x-datadog-*` headers reached that `break` when the Datadog extractor returned `ErrSpanContextNotFound` — stopping the loop *before ever trying the `tracecontext` extractor*, which would have succeeded. The tail then built a baggage-only context and returned `nil` error, so the real trace context was silently discarded instead of being found. **Accepted.** Confirmed against the PR that introduced `DD_TRACE_PROPAGATION_EXTRACT_FIRST`, [#2339](#2339), whose body documents the intended algorithm: step 1 ("if there is no valid trace context, continue to the next propagator") is unconditional; `ExtractFirst` only changes step 2 (stop once a context *is* found). This PR's `break` on failure inverted that — a pre-existing flaw (the original code's `return nil, nil, err` in the same spot had the identical inversion), but this PR's new tail-baggage-merge logic is what turned that quiet failure into a misleading "success." **The fix:** folded the two separate `onlyExtractFirst` checks (one on the failure path, one on the success path) into a single check gated on `extractedCtx != nil`, so `ErrSpanContextNotFound` always falls through to try the next extractor regardless of `onlyExtractFirst` — matching what non-extract-first already does. Hard errors are unaffected; they still bail immediately in both modes. Added `TestExtractFirstContinuesPastFailedExtractor`, confirmed to fail on the pre-fix code and pass after. Re-ran the full `-race` suite, `instrumentation/httptrace`/`contrib/net/http`/`ddtrace/opentelemetry`, `golangci-lint`, `checklocks.sh`, and `benchstat` against the pre-fix tip of this branch — no regressions (geomean deltas within noise: +0.10% time, -0.03% bytes, +0.00% allocs). ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. New/updated: two subtests in `TestPropagationBehaviorExtract` (scenarios A + the bonus ot-baggage bug), `TestExtractOnlyBaggage` parametrized over style × extractFirst (scenario B), `TestExtractBaggageFirstThenDatadog` parametrized over extractFirst (scenario C), `TestExtractFirstContinuesPastFailedExtractor` (the Codex-found regression). Every new assertion was confirmed to fail on the pre-fix code and pass after. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. - [x] There is a benchmark for any new code, or changes to existing code — existing `BenchmarkExtract*`/`BenchmarkInject*` re-run via `benchstat` against baseline; no regressions, `ExtractW3C`/`ExtractW3CUppercase` improved as noted above. - [ ] If this interacts with the agent in a new way, a system test has been added. - [x] New code is free of linting errors. Verified with `golangci-lint run ./ddtrace/tracer/...` (0 issues) and `checklocks.sh` (no new issues; two pre-existing suggestions are in untouched files). - [x] New code doesn't break existing tests. Full `ddtrace/tracer` suite passes with `-race`; `instrumentation/httptrace`, `contrib/net/http`, `ddtrace/opentelemetry` all green. - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [x] All generated files are up to date. - [ ] Non-trivial go.mod changes — N/A, no go.mod changes. No public API changed either (only unexported `chainedPropagator` methods). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dario.castane <dario.castane@datadoghq.com> (cherry picked from commit 150d1cd)
…metry (#5141) ## What does this PR do? Part of a split of [#5122](#5122) into a reviewable stack (see that PR for the full sequence and rationale for the split). `OTEL_TRACES_SPAN_METRICS_ENABLED=false` disables native stats computation when `DD_TRACE_STATS_COMPUTATION_ENABLED` was left at its default. That was done by writing the struct field directly, which skipped `configtelemetry.Report` — so telemetry kept reporting `DD_TRACE_STATS_COMPUTATION_ENABLED` as its default (`true`) while the tracer behaved as `false`, and the discrepancy was invisible from the outside. Routes it through `SetStatsComputationEnabled` with `OriginCalculated`, which is what every other derived value in `loadConfig` does. Safe to call here: the config being built is still local, so taking its mutex cannot contend. ### Motivation Unrelated telemetry-accuracy fix that surfaced while working on the trace-protocol/CSS decoupling in #5122; split out because it's independent of that change. ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [x] New code doesn't break existing tests. You can check this by running `make test` locally. - [x] New code is free of linting errors. You can check this by running `make lint` locally. - [x] All generated files are up to date. You can check this by running `make generate` locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dario.castane <dario.castane@datadoghq.com> # Conflicts: # internal/config/config.go # internal/config/config_test.go
…abled (#5143) ## What does this PR do? Part of a split of [#5122](#5122) into a reviewable stack (see that PR for the full sequence). Stacked on [#5141](#5141) — this PR's diff is scoped to just the change below; merge #5141 first. `TraceProtocol` special-cased `OTLPSpanMetricsEnabled` and returned v0.4 unconditionally, on the rationale that the trace transport "must stay on v0.4 where the Datadog Agent can see the `Datadog-Client-Computed-Stats` header". That rationale doesn't hold: the header is a request header the Agent reads on either protocol, and OTLP span metrics are aggregated by their own concentrator and shipped over the separate `/v0.6/stats` endpoint. Neither depends on the `/vX/traces` wire format. This is the same disproven reasoning as the CSS gate removed by #5122, applied to a second knob, so it goes the same way. ### Cross-repo dependency — already resolved #5122's description flagged a prerequisite: `tests/parametric/test_otlp_trace_metrics.py:264` in `DataDog/system-tests` filtered trace requests on `("/v0.4/traces", "/v0.5/traces", "/v0.7/traces")`, omitting `/v1.0/traces`, so removing this coupling would make that filter return empty for the span-metrics test configuration. That's already fixed: [DataDog/system-tests#7403](DataDog/system-tests#7403) added `/v1.0/traces` to the tuple and merged on 2026-07-29, ahead of this PR. No further system-tests work is needed before this can land. ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [x] New code doesn't break existing tests. You can check this by running `make test` locally. - [x] New code is free of linting errors. You can check this by running `make lint` locally. - [x] All generated files are up to date. You can check this by running `make generate` locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dario.castane <dario.castane@datadoghq.com> # Conflicts: # ddtrace/tracer/option.go # internal/config/config_test.go
(cherry picked from commit bf4a663)
This reverts commit e219f0d.
github-actions
Bot
added
the
apm:ecosystem
Contributor
Config Audit |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 53e4648 | Docs | Datadog PR Page | Give us feedback! |
Backport the govulncheck-specific parts of 9eae137 so checksum and Go cache corruption failures clear the caches and retry without masking real vulnerability findings.
Scoped backport of the span-pool-related pieces from a40b7e5. This restores the deterministic Orchestrion assertion added on main.
\`v0.82.0-rc.2\` is the release candidate for the upcoming \`v0.82.0\` stable release. Once \`v0.82.0\` is officially released, this PR will be updated to pin to the stable tag before merging. - Bumps all \`datadog-agent/*\` packages from \`v0.79.0\` to \`v0.82.0-rc.2\` - Transitive dependencies (otel, grpc, golang.org/x/\*, gopsutil, etc.) updated accordingly - Ran \`scripts/fix_modules.sh\` to tidy all sub-modules This is a prerequisite for the cardinality limits feature PR (#5032) which depends on new APIs in \`pkg/trace/stats\` introduced in v0.82.0. - [ ] CI passes (all go.mod/go.sum checks, unit tests) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: kemal.akkoyun <kemal.akkoyun@datadoghq.com>
Implements the Cardinality Limits RFC for the stats concentrator (client-side stats). - Six per-bucket limits cap distinct values for: `additional_metric_tags`, `whole_key`, `resource`, `http_endpoint`, `peer_tags`, `origin` - Each collapse emits a `datadog.tracer.stats.collapsed_spans` statsd metric and instrumentation telemetry tagged with `collapsed:<field>` - All limits are effectively no-ops by default (high caps); agent PR #52871 wires the actual values - Depends on new `BucketCardinalityLimits`, `SpanCollapseResult`, and `DrainBlockCounts` APIs in `pkg/trace/stats` v0.82.0-rc.2 **New configuration:** | Env var | Option | Default | |---|---|---| | `DD_TRACE_STATS_CARDINALITY_LIMIT` | `WithStatsCardinalityLimit` | 2048 | | `DD_TRACE_STATS_RESOURCE_CARDINALITY_LIMIT` | `WithStatsResourceCardinalityLimit` | 1024 | | `DD_TRACE_STATS_HTTP_ENDPOINT_CARDINALITY_LIMIT` | `WithStatsHTTPEndpointCardinalityLimit` | 512 | | `DD_TRACE_STATS_PEER_TAGS_CARDINALITY_LIMIT` | `WithStatsPeerTagsCardinalityLimit` | 512 | | `DD_TRACE_STATS_ORIGIN_CARDINALITY_LIMIT` | `WithStatsOriginCardinalityLimit` | 20 | > Stacked on #5031 — review that first, then this PR shows only the feature diff. - [ ] `go test ./ddtrace/tracer/... -run TestFlushAndSendCollapsedSpansMetric` — 6 collapse metric tests - [ ] `go test ./internal/config/...` — telemetry setter and cardinality config tests 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: darccio <dario.castane@datadoghq.com> Co-authored-by: sam.maya <sam.maya@datadoghq.com>
BenchmarksBenchmark execution time: 2026-08-10 14:28:15 Comparing candidate commit 53e4648 in PR branch Found 38 performance improvements and 6 performance regressions! Performance is the same for 257 metrics, 1 unstable metrics, 1 flaky benchmarks without significant changes.
|
Bumps `datadog-agent/pkg/*` dependencies to v0.82.0 - released on Aug 4th - as required version to cover #5032. - [ ] Changed code has unit tests for its functionality at or near 100% coverage. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. - [ ] There is a benchmark for any new code, or changes to existing code. - [ ] If this interacts with the agent in a new way, a system test has been added. - [ ] New code is free of linting errors. You can check this by running `make lint` locally. - [ ] New code doesn't break existing tests. You can check this by running `make test` locally. - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [ ] All generated files are up to date. You can check this by running `make generate` locally. - [ ] Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally. Unsure? Have a question? Request a review! Co-authored-by: dario.castane <dario.castane@datadoghq.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 53e4648e3a
ℹ️ 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 was referenced Aug 10, 2026
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
3 participants
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.
What does this PR do?
Backports:
v2.10.0release branch.Some additional backports have been done to fix CI (although
govunlcheckwon't be fixed because bumping gRPC is too heavy for our current dogfooding process):Motivation
Delivering a more optimized hot-path for starting spans and context propagation, and decoupling ETP from CSS.
Reviewer's Checklist
make lintlocally.make testlocally.make generatelocally.make fix-moduleslocally.Unsure? Have a question? Request a review!