Skip to content

feat!: weekly job to have timings of the tests and benchmark per crate - #2697

Open
Aaalibaba42 wants to merge 16 commits into
mainfrom
jwiriath/measure-of-time-to-run
Open

feat!: weekly job to have timings of the tests and benchmark per crate#2697
Aaalibaba42 wants to merge 16 commits into
mainfrom
jwiriath/measure-of-time-to-run

Conversation

@Aaalibaba42

@Aaalibaba42 Aaalibaba42 commented Oct 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

What does this PR do?

Adds a weekly job that reports the timing of each tests and benchmarks.

Motivation

We have done a lot of work on the ci and testing infrastructure and workflow logics, but we did not dive into if whatever we are testing/benchmarking made sense, and how much they contributed to the running times. This should help drive the decision, without impacting PR/mq merge times.

Additional Notes

@datadog-official

datadog-official Bot commented Oct 19, 2026 •
edited by datadog-datadog-prod-us1 Bot
Loading

Copy link
Copy Markdown

Pipelines  Tests

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 2 Pipeline jobs failed

semver-check | semver-check — 🔧 Needs a code fix, caused by this PR

View more details · View in GitHub Actions

Required checks pass | allchecks

View more details · View in GitHub Actions

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 17.34%
• Overall Coverage: 84.78% (+2.12%)

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4b55c18 | Docs | View more details | Give us feedback!

@pr-commenter

pr-commenter Bot commented Oct 19, 2026 •
edited
Loading

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-10-26 15:51:00

Comparing candidate commit 4b55c18 in PR branch jwiriath/measure-of-time-to-run with baseline commit 83c9c89 in branch main.

📊 Benchmarking dashboard

Found 9 performance improvements and 26 performance regressions! Performance is the same for 104 metrics, 4 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:agentless_encoding/common_http/20x5

  • 🟩 execution_time [-8.528µs; -8.469µs] or [-7.350%; -7.300%]
  • 🟩 throughput [+67901.380op/s; +68350.445op/s] or [+7.878%; +7.930%]

scenario:agentless_encoding/http_with_span_links/20x5

  • 🟩 execution_time [-9.898µs; -9.824µs] or [-7.496%; -7.440%]
  • 🟩 throughput [+60899.387op/s; +61351.530op/s] or [+8.041%; +8.101%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟥 execution_time [+5.383µs; +5.460µs] or [+7.896%; +8.009%]
  • 🟥 throughput [-1087792.166op/s; -1073197.234op/s] or [-7.416%; -7.316%]

scenario:credit_card/is_card_number/378282246310005

  • 🟥 execution_time [+5.930µs; +5.994µs] or [+9.154%; +9.253%]
  • 🟥 throughput [-1307419.471op/s; -1294222.225op/s] or [-8.470%; -8.384%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟥 execution_time [+7.159µs; +7.190µs] or [+15.889%; +15.957%]
  • 🟥 throughput [-3054540.968op/s; -3042377.509op/s] or [-13.763%; -13.708%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟥 execution_time [+3.795µs; +3.845µs] or [+7.054%; +7.147%]
  • 🟥 throughput [-1240156.384op/s; -1224454.724op/s] or [-6.672%; -6.587%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟥 execution_time [+4.668µs; +4.725µs] or [+9.296%; +9.410%]
  • 🟥 throughput [-1712904.929op/s; -1693309.797op/s] or [-8.601%; -8.503%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟥 execution_time [+7.208µs; +7.231µs] or [+15.996%; +16.047%]
  • 🟥 throughput [-3069196.500op/s; -3059647.085op/s] or [-13.830%; -13.787%]

scenario:otlp/e2e_json/1x1000

  • 🟩 execution_time [-359.380µs; -352.266µs] or [-8.204%; -8.042%]

scenario:otlp/encode_json/1x1000

  • 🟩 execution_time [-350.068µs; -349.404µs] or [-17.495%; -17.462%]

scenario:vec_map/as_deduped_map/already_deduped/8

  • 🟩 execution_time [-1.096ns; -1.053ns] or [-6.807%; -6.544%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/64

  • 🟥 execution_time [+61.594ns; +67.860ns] or [+5.048%; +5.561%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/64

  • 🟥 execution_time [+93.588ns; +98.402ns] or [+7.177%; +7.546%]

scenario:vec_map/contains_key/128

  • 🟥 execution_time [+807.205ns; +831.954ns] or [+5.417%; +5.583%]
  • 🟥 throughput [-454219.683op/s; -441319.799op/s] or [-5.288%; -5.138%]

scenario:vec_map/contains_key/64

  • 🟥 execution_time [+209.516ns; +215.215ns] or [+5.233%; +5.375%]
  • 🟥 throughput [-815813.311op/s; -794392.066op/s] or [-5.104%; -4.970%]

scenario:vec_map/contains_key/8

  • 🟥 execution_time [+4.472ns; +4.723ns] or [+6.391%; +6.748%]
  • 🟥 throughput [-7239793.336op/s; -6857803.937op/s] or [-6.333%; -5.999%]

scenario:vec_map/dedup/dup_1_in_10/8

  • 🟥 execution_time [+8.740ns; +11.631ns] or [+4.268%; +5.679%]

scenario:vec_map/dedup/dup_1_in_2/8

  • 🟥 execution_time [+14.185ns; +26.392ns] or [+4.831%; +8.989%]

scenario:vec_map/get_hit/128

  • 🟥 execution_time [+1.270µs; +1.289µs] or [+10.265%; +10.419%]
  • 🟥 throughput [-976571.706op/s; -962910.237op/s] or [-9.438%; -9.306%]

scenario:vec_map/get_hit/64

  • 🟥 execution_time [+2.466µs; +2.474µs] or [+72.902%; +73.156%]
  • 🟥 throughput [-8000598.352op/s; -7971412.017op/s] or [-42.283%; -42.129%]

scenario:vec_map/get_hit/8

  • 🟩 execution_time [-7.768ns; -7.297ns] or [-12.639%; -11.873%]
  • 🟩 throughput [+17676774.935op/s; +18598629.054op/s] or [+13.575%; +14.283%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:span_pool/allocated_bytes/1x10/pooled

  • unstable execution_time [-90.345ns; +693.517ns] or [-8.871%; +68.097%]
  • unstable throughput [-134651910.515op/s; +26600836.396op/s] or [-218.530%; +43.171%]

scenario:vec_map/get_mut/8

  • unstable execution_time [-3.870ns; +7.581ns] or [-4.372%; +8.563%]
  • unstable throughput [-8501933.519op/s; +4207975.588op/s] or [-8.885%; +4.398%]
Benchmark execution time: 2026-10-26 15:55:16

Comparing candidate commit 4b55c18 in PR branch jwiriath/measure-of-time-to-run with baseline commit 83c9c89 in branch main.

📊 Benchmarking dashboard

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

scenario:thread_cpu/alloc_free/system/4096

  • 🟩 execution_time [-20.090ns; -19.955ns] or [-18.847%; -18.721%]

scenario:thread_cpu/profiler_attached/slow_path_system/4096

  • 🟩 execution_time [-12.178ns; -12.066ns] or [-7.862%; -7.790%]

scenario:write only interface

  • 🟩 execution_time [-33.487ns; -28.361ns] or [-6.428%; -5.444%]

Benchmark execution time: 2026-10-26 16:00:44

Comparing candidate commit 4b55c18 in PR branch jwiriath/measure-of-time-to-run with baseline commit 83c9c89 in branch main.

📊 Benchmarking dashboard

Found 0 performance improvements and 4 performance regressions! Performance is the same for 67 metrics, 25 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:glob_matcher/ascii_case_insensitive_match/wall_time

  • 🟥 execution_time [+2.669ns; +2.698ns] or [+9.585%; +9.689%]

scenario:glob_matcher/ascii_exact_match/wall_time

  • 🟥 execution_time [+3.287ns; +3.324ns] or [+12.066%; +12.201%]

scenario:glob_matcher/ascii_exact_miss/wall_time

  • 🟥 execution_time [+3.695ns; +3.757ns] or [+30.961%; +31.479%]

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

  • 🟥 execution_time [+4.515ns; +4.628ns] or [+4.977%; +5.102%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:datadog_sample_span/complex_rule_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+549.848%; -552.973%]

scenario:datadog_sample_span/complex_rule_partial_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/many_attributes_tag_rule/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+548.052%; -552.134%]

scenario:datadog_sample_span/multiple_rules_first_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+559.026%; -557.287%]

scenario:datadog_sample_span/multiple_rules_last_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+548.949%; -552.553%]

scenario:datadog_sample_span/name_pattern_rule_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+544.789%; -550.614%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+582.635%; -568.573%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

  • unstable execution_time [-40.587ns; -23.142ns] or [-24.349%; -13.883%]

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+555.367%; -555.561%]

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+556.288%; -555.995%]

scenario:datadog_sample_span/resource_pattern_rule_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/resource_pattern_rule_not_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+561.390%; -558.405%]

scenario:datadog_sample_span/root_span_no_rules/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+563.893%; -559.592%]

scenario:datadog_sample_span/service_rule_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+562.822%; -559.083%]

scenario:datadog_sample_span/service_rule_not_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/tag_rule_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+548.696%; -552.435%]

scenario:datadog_sample_span/tag_rule_not_matching/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+553.376%; -554.626%]

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+590.230%; -572.256%]

scenario:glob_matcher/ascii_exact_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+593.026%; -573.618%]

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+637.542%; -595.696%]

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+565.378%; -560.297%]

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+564.394%; -559.830%]

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+561.237%; -558.332%]

scenario:glob_matcher/star_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+556.408%; -556.052%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@github-actions

github-actions Bot commented Oct 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 12 issue(s) found, showing only errors (advisories, bans, sources)

📦 libdd-trace-utils - 5 error(s)

Show output 
info: syncing channel updates for 1.87.0-x86_64-unknown-linux-gnu
info: latest update on 2025-05-15 for version 1.87.0 (17067e9ac 2025-05-09)
info: downloading 6 components
warn: the missing active toolchain `1.87.0-x86_64-unknown-linux-gnu` has been auto-installed
warn: this might cause rustup commands to take longer time to finish than expected
info: you may opt out with `RUSTUP_AUTO_INSTALL=0` or `rustup set auto-install disable`
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:215:1
    │
215 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/pull/3265
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v8.0.0 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:215:1
    │
215 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0346
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
    ├ The `Debug` implementations of `Tls12ClientSessionValue` and
      `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
      secret or TLS 1.3 resumption PSK in their output.
      
      Custom `ClientSessionStore` implementations that format these values with
      `Debug` (for example, when logging) could disclose these secrets to readers of
      the logs. This conflicts with rustls's
      [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
      
      Ordinary connection and built-in session cache `Debug` output is redacted and
      is not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3299
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v8.0.0 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:215:1
    │
215 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0348
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
    ├ The built-in Brotli certificate decompressor (enabled by the non-default
      `brotli` crate feature) bounded the size of the decompressed output, but
      accepted a peer-selected history window. Brotli's large-window extension was
      enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
      abort a process whose allocator cannot satisfy that request.
      
      No trusted certificate is required by the attacker. Affected configurations are:
      
      - clients that enable the `brotli` feature and connect to a malicious server, and
      - servers that enable the `brotli` feature and request client certificates.
      
      Applications that do not enable the `brotli` feature are not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3297
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v8.0.0 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:215:1
    │
215 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0349
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
    ├ The client recorded the server-selected key exchange group for each server
      name when processing the ServerHello, before the server was authenticated.
      This record is used to predict which key share to send in future ClientHellos
      to that server name.
      
      A network attacker can answer one connection attempt with a ServerHello
      selecting X25519, and then close the connection. Later ClientHellos for that
      name carry only an X25519 key share, while `supported_groups` still lists
      X25519MLKEM768 first. If the genuine server accepts that share rather than
      sending a HelloRetryRequest for its preferred hybrid group, the handshake
      completes with classical-only key exchange and no error. This persists for as
      long as the entry stays in the client's session store.
      
      The impact is loss of post-quantum confidentiality for affected connections
      ("harvest now, decrypt later"). There is no key compromise and no
      authentication bypass.
      
      The following are not affected:
      
      - connections to servers which send a HelloRetryRequest for their preferred group,
      - clients with resumption disabled (as nothing is stored), and
      - other server names.
      
      This behaviour is discussed in
      [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
      so the practical impact depends largely on server policy.
    ├ Announcement: https://github.com/rustls/rustls/pull/3355
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v8.0.0 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:266:1
    │
266 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── h2 v0.4.19
      │   └── hyper v1.11.1
      │       ├── httpmock v0.8.0-alpha.1
      │       │   └── libdd-trace-utils v14.0.0
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── hyper-rustls v0.27.7
      │       │   └── libdd-common v8.0.0
      │       │       ├── libdd-capabilities-impl v7.0.0
      │       │       │   └── libdd-trace-utils v14.0.0 (*)
      │       │       └── libdd-trace-utils v14.0.0 (*)
      │       ├── hyper-util v0.1.17
      │       │   ├── httpmock v0.8.0-alpha.1 (*)
      │       │   ├── hyper-rustls v0.27.7 (*)
      │       │   └── libdd-common v8.0.0 (*)
      │       ├── libdd-common v8.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── httpmock v0.8.0-alpha.1 (*)
      ├── hyper v1.11.1 (*)
      ├── hyper-rustls v0.27.7 (*)
      ├── hyper-util v0.1.17 (*)
      ├── (dev) libdd-capabilities-impl v7.0.0 (*)
      ├── (dev) libdd-common v8.0.0 (*)
      ├── (dev) libdd-trace-protobuf v5.1.0
      │   ├── libdd-trace-normalization v4.2.0
      │   │   └── libdd-trace-utils v14.0.0 (*)
      │   └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-trace-utils v14.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   ├── hyper-rustls v0.27.7 (*)
      │   └── (dev) libdd-common v8.0.0 (*)
      └── tokio-util v0.7.12
          └── h2 v0.4.19 (*)

advisories FAILED, bans ok, sources ok

📦 tools - 7 error(s)

Show output 
error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:82:1
   │
82 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v46.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:82:1
   │
82 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v46.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:96:1
   │
96 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0285
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
   ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
     when they followed a key-changing message in the same record. For example,
     a plaintext `EncryptedExtensions` message packed into the same record as the
     `ServerHello` was accepted.
     
     RFC 8446 section 5.1 requires that handshake messages do not span key changes,
     and that implementations terminate the connection with an "unexpected_message"
     alert if they do.
     
     The handshake transcript is still authenticated, so a network-position attacker
     cannot use this to alter or complete a handshake; the practical effect is that
     a peer could send handshake messages that should be encrypted in plaintext
     without rustls rejecting the connection.
     
     This is functionally the same bug as Go's
     [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
   ├ Announcement: https://github.com/rustls/rustls/pull/3265
   ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     └── tokio-rustls v0.26.0
         └── (dev) libdd-common v8.0.0
             └── tools v46.0.0

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:96:1
   │
96 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0346
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
   ├ The `Debug` implementations of `Tls12ClientSessionValue` and
     `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
     secret or TLS 1.3 resumption PSK in their output.
     
     Custom `ClientSessionStore` implementations that format these values with
     `Debug` (for example, when logging) could disclose these secrets to readers of
     the logs. This conflicts with rustls's
     [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
     
     Ordinary connection and built-in session cache `Debug` output is redacted and
     is not affected.
   ├ Announcement: https://github.com/rustls/rustls/pull/3299
   ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     └── tokio-rustls v0.26.0
         └── (dev) libdd-common v8.0.0
             └── tools v46.0.0

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:96:1
   │
96 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0348
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
   ├ The built-in Brotli certificate decompressor (enabled by the non-default
     `brotli` crate feature) bounded the size of the decompressed output, but
     accepted a peer-selected history window. Brotli's large-window extension was
     enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
     abort a process whose allocator cannot satisfy that request.
     
     No trusted certificate is required by the attacker. Affected configurations are:
     
     - clients that enable the `brotli` feature and connect to a malicious server, and
     - servers that enable the `brotli` feature and request client certificates.
     
     Applications that do not enable the `brotli` feature are not affected.
   ├ Announcement: https://github.com/rustls/rustls/pull/3297
   ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     └── tokio-rustls v0.26.0
         └── (dev) libdd-common v8.0.0
             └── tools v46.0.0

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:96:1
   │
96 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0349
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
   ├ The client recorded the server-selected key exchange group for each server
     name when processing the ServerHello, before the server was authenticated.
     This record is used to predict which key share to send in future ClientHellos
     to that server name.
     
     A network attacker can answer one connection attempt with a ServerHello
     selecting X25519, and then close the connection. Later ClientHellos for that
     name carry only an X25519 key share, while `supported_groups` still lists
     X25519MLKEM768 first. If the genuine server accepts that share rather than
     sending a HelloRetryRequest for its preferred hybrid group, the handshake
     completes with classical-only key exchange and no error. This persists for as
     long as the entry stays in the client's session store.
     
     The impact is loss of post-quantum confidentiality for affected connections
     ("harvest now, decrypt later"). There is no key compromise and no
     authentication bypass.
     
     The following are not affected:
     
     - connections to servers which send a HelloRetryRequest for their preferred group,
     - clients with resumption disabled (as nothing is stored), and
     - other server names.
     
     This behaviour is discussed in
     [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
     so the practical impact depends largely on server policy.
   ├ Announcement: https://github.com/rustls/rustls/pull/3355
   ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     └── tokio-rustls v0.26.0
         └── (dev) libdd-common v8.0.0
             └── tools v46.0.0

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:124:1
    │
124 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── (dev) libdd-common v8.0.0
      │   └── tools v46.0.0
      └── tokio-rustls v0.26.0
          └── (dev) libdd-common v8.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-10-26 15:29:49 UTC | Commit: f343d40 | dependency-check job results

@github-actions

github-actions Bot commented Oct 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 953 documentation warning(s) found

📦 libdd-trace-utils - 795 warning(s)

📦 tools - 158 warning(s)

Updated: 2026-10-26 15:30:04 UTC | Commit: f343d40 | missing-docs job results

@Aaalibaba42
Aaalibaba42 marked this pull request as ready for review October 21, 2026 09:46
@Aaalibaba42
Aaalibaba42 requested review from a team as code owners October 21, 2026 09:46
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 21, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review 🔄 Running since 2026-10-21T09:46:33.742560Z 0ba8cf9 Draft marked ready
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@Aaalibaba42
Aaalibaba42 force-pushed the jwiriath/measure-of-time-to-run branch from 0ba8cf9 to e8cfcca Compare October 21, 2026 09:56
@Aaalibaba42
Aaalibaba42 force-pushed the jwiriath/measure-of-time-to-run branch from e39458e to 7145851 Compare October 21, 2026 10:00
@Aaalibaba42
Aaalibaba42 requested a review from a team as a code owner October 23, 2026 13:42
ekump
ekump reviewed Oct 23, 2026
View reviewed changes
Comment thread .github/workflows/crate-timing.yml
Comment thread tools/src/bin/crate_timing.rs Outdated
Comment thread .github/workflows/crate-timing.yml
Comment thread tools/src/bin/crate_timing.rs Outdated
Comment thread tools/src/junit.rs Outdated
Comment thread tools/src/bin/crate_timing.rs
Comment thread tools/src/bin/crate_timing.rs Outdated
@Aaalibaba42 Aaalibaba42 changed the title feat: weekly job to have timings of the tests and benchmark per crate feat!: weekly job to have timings of the tests and benchmark per crate Oct 26, 2026
@Aaalibaba42
Aaalibaba42 force-pushed the jwiriath/measure-of-time-to-run branch from 53ea3ff to 4b55c18 Compare October 26, 2026 15:27
@dd-octo-sts

dd-octo-sts Bot commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 9.08 MB 9.08 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 96.63 MB 96.63 MB +0% (+3.97 KB) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.29 MB 12.29 MB -0% (-464 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 107.98 MB 107.98 MB -0% (-5.53 KB) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 29.23 MB 29.24 MB +.03% (+9.00 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 99.56 KB 99.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 193.11 MB 193.19 MB +.04% (+88.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 821.00 MB 820.86 MB --.01% (-143.97 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.81 MB 9.81 MB +.02% (+2.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 99.56 KB 99.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 27.61 MB 27.62 MB +.05% (+16.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 55.90 MB 55.92 MB +.03% (+17.71 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 25.65 MB 25.65 MB +.01% (+3.00 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 101.12 KB 101.12 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 198.75 MB 198.83 MB +.03% (+80.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 809.66 MB 808.64 MB --.12% (-1.01 MB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.60 MB 7.60 MB +.01% (+1.00 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 101.12 KB 101.12 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 29.76 MB 29.76 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 52.83 MB 52.83 MB -0% (-1.09 KB) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 86.53 MB 86.54 MB +.01% (+15.27 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.12 MB 10.13 MB +.03% (+4.00 KB) 🔍
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.45 MB 102.44 MB --.01% (-15.36 KB) 💪
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.37 MB 12.38 MB +.02% (+3.51 KB) 🔍

This branch has not been deployed

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

Reviewers

@ekump ekump ekump left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

ci-build mini-agent

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Aaalibaba42 @ekump