Skip to content

fix(sidecar): don't double-encode file:// telemetry endpoints - #2230

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 1 commit into
mainfrom
glopes/fix-telemetry-endpoint-double-encoding
Jul 13, 2026
Merged

fix(sidecar): don't double-encode file:// telemetry endpoints#2230
gh-worker-dd-mergequeue-cf854d[bot] merged 1 commit into
mainfrom
glopes/fix-telemetry-endpoint-double-encoding

Conversation

@cataphract

Copy link
Copy Markdown
Contributor

What changed

  • Add Config::set_endpoint_uri for integrations that already hold a parsed URI.
  • Use the parsed-URI path in sidecar session telemetry and crashtracker telemetry instead of stringifying and reparsing endpoints.
  • Preserve the telemetry-owned TelemetryEndpoint primitive configuration API.
  • Document the non-idempotent behavior of parse_uri for file, Unix socket, and Windows pipe schemes.
  • Add regression coverage for parsed file:// endpoints.

Why

Sidecar session setup converted an already-parsed endpoint URI back to a string and passed it through parse_uri again. For file:// endpoints, the path is encoded into the URI authority, so parsing the string representation a second time encoded the authority again. Telemetry then opened the wrong file path and the worker failure tore down the sidecar IPC connection.

The fix gives parsed-URI callers an explicit path while keeping the public configuration boundary introduced for telemetry consumers.

Validation

  • cargo check -p libdd-telemetry -p libdd-crashtracker -p datadog-sidecar
  • cargo test -p libdd-telemetry config::tests::test_config_set_parsed_file_uri_does_not_reencode_path -- --exact
  • Full workspace formatting and clippy, targeted telemetry/FFI/data-pipeline/sidecar/crashtracker tests, and telemetry FFI examples were run before rebasing onto origin/main.

The per-session self-telemetry setup stringified an already-parsed
session endpoint URI and passed it to telemetry Config::set_endpoint.
For file:// endpoints, parse_uri then encoded the URI authority a second
time, causing the telemetry file client to open the wrong path and tear
down telemetry.

Preserve the telemetry-owned TelemetryEndpoint configuration API
introduced by #2152. Add Config::set_endpoint_uri for integrations that
already hold an http::Uri, and use it from the sidecar and crashtracker
so parsed endpoints are never stringified and reparsed. String and FFI
callers continue to use the primitive patch API and parse their original
URL exactly once.

Document that parse_uri is not idempotent for file, unix, and windows
schemes, and add regression coverage for passing a parsed file URI
without re-encoding its path.

Copy link
Copy Markdown
Contributor Author

This fixes a regression introduced by commit b3144c676b73e157f9d563903c01df016882e8c4 in #2152. That refactor made telemetry endpoint configuration stringify an already-parsed Uri; for file:// endpoints, passing that string through parse_uri again double-encoded the path stored in the URI authority.

@cataphract
cataphract marked this pull request as ready for review July 12, 2026 14:54
@cataphract
cataphract requested review from a team as code owners July 12, 2026 14:54
@github-actions

Copy link
Copy Markdown
Contributor

Clippy Allow Annotation Report

Comparing clippy allow annotations between branches:

  • Base Branch: origin/main
  • PR Branch: origin/glopes/fix-telemetry-endpoint-double-encoding

Summary by Rule

Rule Base Branch PR Branch Change
expect_used 2 2 No change (0%)
unwrap_used 10 10 No change (0%)
Total 12 12 No change (0%)

Annotation Counts by File

File Base Branch PR Branch Change
datadog-sidecar/src/service/sidecar_server.rs 6 6 No change (0%)
libdd-common/src/lib.rs 6 6 No change (0%)

Annotation Stats by Crate

Crate Base Branch PR Branch Change
clippy-annotation-reporter 5 5 No change (0%)
datadog-ffe-ffi 1 1 No change (0%)
datadog-ipc 22 22 No change (0%)
datadog-live-debugger 4 4 No change (0%)
datadog-live-debugger-ffi 10 10 No change (0%)
datadog-profiling-replayer 4 4 No change (0%)
datadog-sidecar 45 45 No change (0%)
libdd-common 13 13 No change (0%)
libdd-common-ffi 12 12 No change (0%)
libdd-data-pipeline 6 6 No change (0%)
libdd-ddsketch 2 2 No change (0%)
libdd-dogstatsd-client 1 1 No change (0%)
libdd-profiling 13 13 No change (0%)
libdd-remote-config 3 3 No change (0%)
libdd-telemetry 20 20 No change (0%)
libdd-tinybytes 4 4 No change (0%)
libdd-trace-normalization 2 2 No change (0%)
libdd-trace-obfuscation 3 3 No change (0%)
libdd-trace-stats 1 1 No change (0%)
libdd-trace-utils 11 11 No change (0%)
Total 182 182 No change (0%)

About This Report

This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality.

@datadog-prod-us1-5

datadog-prod-us1-5 Bot commented Jul 12, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 91.30%
Overall Coverage: 74.49% (+0.00%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b113705 | Docs | Datadog PR Page | Give us feedback!

@pr-commenter

pr-commenter Bot commented Jul 12, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-12 15:23:46

Comparing candidate commit b113705 in PR branch glopes/fix-telemetry-endpoint-double-encoding with baseline commit ade7821 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 123 metrics, 0 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 ----------------------------------'

Benchmark execution time: 2026-07-12 15:28:58

Comparing candidate commit b113705 in PR branch glopes/fix-telemetry-endpoint-double-encoding with baseline commit ade7821 in branch main.

Found 2 performance improvements and 5 performance regressions! Performance is the same for 100 metrics, 10 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:credit_card/is_card_number/37828224631000521389798

  • 🟥 execution_time [+10.164µs; +10.195µs] or [+22.225%; +22.292%]
  • 🟥 throughput [-3987700.064op/s; -3974227.950op/s] or [-18.237%; -18.176%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟥 execution_time [+10.169µs; +10.200µs] or [+22.237%; +22.305%]
  • 🟥 throughput [-3990259.896op/s; -3976220.753op/s] or [-18.247%; -18.183%]

scenario:receiver_entry_point/report/2644

  • 🟥 execution_time [+156.519µs; +166.129µs] or [+4.655%; +4.940%]

scenario:trace_buffer/4_senders/no_delay

  • 🟩 execution_time [-222.777µs; -191.931µs] or [-8.934%; -7.697%]
  • 🟩 throughput [+122411.487op/s; +142916.093op/s] or [+8.474%; +9.894%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@dd-octo-sts

dd-octo-sts Bot commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 86.15 MB 86.15 MB -0% (-1.49 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 7.88 MB 7.88 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.62 MB 10.62 MB +0% (+192 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.40 MB 97.40 MB -0% (-1.50 KB) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 25.54 MB 25.54 MB +0% (+512 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 88.44 KB 88.44 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 185.33 MB 185.33 MB +0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 957.25 MB 957.25 MB +0% (+2.39 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.35 MB 8.35 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 88.44 KB 88.44 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 24.72 MB 24.72 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 49.21 MB 49.21 MB +0% (+560 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 22.19 MB 22.19 MB +0% (+1.00 KB) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 89.82 KB 89.82 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 189.78 MB 189.80 MB +0% (+16.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 945.93 MB 945.93 MB +0% (+2.36 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.46 MB 6.46 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 89.82 KB 89.82 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 26.54 MB 26.54 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 46.82 MB 46.82 MB +0% (+854 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 76.97 MB 76.96 MB -0% (-2.10 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 8.81 MB 8.81 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 92.38 MB 92.37 MB -0% (-2.06 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.72 MB 10.72 MB --.03% (-3.85 KB) 💪

@bwoebi bwoebi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugly workaround, but makes sense.

@cataphract

Copy link
Copy Markdown
Contributor Author

/merge

@gh-worker-devflow-routing-ef8351

gh-worker-devflow-routing-ef8351 Bot commented Jul 13, 2026

Copy link
Copy Markdown

View all feedbacks in Devflow UI.

2026-07-13 12:25:18 UTC ℹ️ Start processing command /merge


2026-07-13 12:25:23 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 1h (p90).


2026-07-13 13:11:25 UTC ℹ️ MergeQueue: This merge request was merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants