[NO-TICKET] Upgrade libdatadog dependency to version 30.0.0#5574
[NO-TICKET] Upgrade libdatadog dependency to version 30.0.0#5574
Conversation
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.
...it also triggers the problematic code.
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.
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: aaf52d8 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
BenchmarksBenchmark execution time: 2026-04-09 18:38:53 Comparing candidate commit aaf52d8 in PR branch Found 2 performance improvements and 0 performance regressions! Performance is the same for 43 metrics, 1 unstable metrics.
|
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.