Skip to content

[NO-TICKET] Upgrade libdatadog dependency to version 30.0.0#5574

Merged
ivoanjo merged 6 commits intomasterfrom
ivoanjo/libdatadog-v30-upgrade
Apr 10, 2026
Merged

[NO-TICKET] Upgrade libdatadog dependency to version 30.0.0#5574
ivoanjo merged 6 commits intomasterfrom
ivoanjo/libdatadog-v30-upgrade

Conversation

@ivoanjo
Copy link
Copy Markdown
Member

@ivoanjo ivoanjo commented Apr 9, 2026

What does this PR do?

This PR bumps the libdatadog dependency from version 29.0.0.1.0 to 30.0.0.1.0.

Motivation:

Fix #5508

Change log entry

Yes. Upgrade libdatadog dependency to version 30.0.0 and fix #5508 failure to initialize transport in profiling

Additional Notes:

The valgrind issue was a bit of a curve-ball, but @yannham is going to change the code to not use rustix and thus not trigger the problem.

How to test the change?

Green CI is good, as usual.

I've manually tested that the issue from #5508 is gone; I'm not sure it's worth adding a test for it on the dd-trace-rb side since a) we've added a test on the libdatadog side and the regression was fully there; and b) it's awkward to run and maintain since it needs its own container with a very specific setup to trigger.

ivoanjo and others added 6 commits April 9, 2026 19:11
The way to specify the `endpoint` was changed in
DataDog/libdatadog#1705 so this updates it to
match.
**What does this PR do?**

This PR bumps the libdatadog dependency from version 29.0.0.1.0 to
30.0.0.1.0.

**Motivation:**

Fix #5508

**Additional Notes:**

N/A

**How to test the change?**

Green CI is good, as usual. I've manually tested that the issue from
 #5508 is gone; I'm not sure it's worth adding a test for it on
the dd-trace-rb side since a) we've added a test on the libdatadog side
and the regression was fully there; and b) it's awkward to run and
maintain since it needs its own container with a very specific setup
to trigger.
As part of upgrading Ruby from libdatadog v29 to v30 we started having
a flaky test failure related to crashtracking.

It turns out the following happened:

1. We support reconfiguration of things such as the agent url. Thus we
   need to know if we need to call `ddog_crasht_init` (first call) or
   `ddog_crasht_reconfigure` (afterwards).
2. We keep a `static bool first_init = false` to know which one to call
3. We have a test that passes the agent url as an invalid ipv6 address
   -- `http://1234:1234::1/`. This test exists because in the past we
   actually had a crash due to not handling this error case correctly
   -- see #4237 &&
   https://datadoghq.atlassian.net/browse/APMLP-350 .
4. In the past, we had `ddog_endpoint_from_url`. That API validated the
   url and told us when it wasn't valid. If we had an invalid endpoint,
   we never called `ddog_crasht_init` and never set `first_init = true`
5. With the v30 new API, the endpoint check happens inside
   `ddog_crasht_init`. This means `ddog_crasht_init` **fails** on the
   wrong url. Then we were setting `first_init = true` inconditionally.
6. The flakiness in our test suite came from -- the test in 3. running
   before or after the other tests. If it ran before, it left the
   crashtracker in a broken state, and it could never recover.
@ivoanjo ivoanjo requested review from a team as code owners April 9, 2026 18:15
@ivoanjo ivoanjo requested a review from eregon April 9, 2026 18:15
@datadog-datadog-prod-us1
Copy link
Copy Markdown
Contributor

datadog-datadog-prod-us1 bot commented Apr 9, 2026

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 95.36% (-0.01%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: aaf52d8 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!

@pr-commenter
Copy link
Copy Markdown

pr-commenter bot commented Apr 9, 2026

Benchmarks

Benchmark execution time: 2026-04-09 18:38:53

Comparing candidate commit aaf52d8 in PR branch ivoanjo/libdatadog-v30-upgrade with baseline commit 2365975 in branch master.

Found 2 performance improvements and 0 performance regressions! Performance is the same for 43 metrics, 1 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:profiling - estimated profiler gc per minute (sample 60000 times + serialize result)

  • 🟩 throughput [+1.498op/s; +1.513op/s] or [+67.461%; +68.133%]

scenario:profiling - profiler gc

  • 🟩 throughput [+29235.328op/s; +30839.469op/s] or [+9.332%; +9.844%]

Comment thread datadog.gemspec
@ivoanjo ivoanjo merged commit 058c2b8 into master Apr 10, 2026
642 of 643 checks passed
@ivoanjo ivoanjo deleted the ivoanjo/libdatadog-v30-upgrade branch April 10, 2026 09:20
@github-actions github-actions bot added this to the 2.31.0 milestone Apr 10, 2026
@y9v y9v mentioned this pull request Apr 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: Profiling regression in 2.30.0 due to "Failed to initialize transport ... No CA certificates were loaded from the system"

2 participants