libdatadog update to b10b1d46

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	b10b1d46577e95e057bd2b310641f965e6167d58

Full CI result: ❌ 197 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/119878822

---

libdatadog Integration Report

libdatadog SHA: b10b1d46577e95e057bd2b310641f965e6167d58
Analysis date: 2026-06-19

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

All 197 failed jobs across the tracer, appsec, profiler, shared, and package
sub-pipelines share a single root cause: a Rust compilation error in our
components-rs/telemetry.rs. Every failing job is a downstream consequence —
the extension (ddtrace.so / libdatadog_php.a) never links, so all the test,
coverage, pecl, windows, and asan jobs that depend on a built extension fail in
turn.

Concretely:

• 84 jobs reached the Rust compile step and reported the same single error
  (error[E0308] at components-rs/telemetry.rs:325, "due to 1 previous
  error"). amd64, arm64, musl, and windows all show it identically.
• The remaining failing jobs (Extension Tea / ZAI / Zend Abstract Interface
  tests, appsec extension/integration tests, pecl tests, benchmarks) consume the
  artifact produced by the broken build and fail because it was never produced.

No second, independent compilation error was reported in any trace — fixing this
one call site should unblock the whole pipeline.

Non-trivial changes made

components-rs/telemetry.rs

OneWayShmReader::new changed signature in libdatadog. This is from the breaking
commit 7370f1488 refactor(shm)!: Extract one_way_shared_memory to IPC and prepare libdd-remote-config for python (#2121), which split the reader's
construction into two constructors:

• new(handle: MappedMem<T>, extra: D) — now takes a non-optional, already
  mapped segment and installs no opener. A reader built this way stays inert
  until a handle is supplied.
• new_with_opener(handle: Option<MappedMem<T>>, extra: D, opener) — takes an
  optional handle plus a re-opener used to (re)map the segment lazily when the
  handle is absent. This is the behaviour the old new(Option, extra) provided
  for named segments.

Our telemetry shm-cache reader opens a named segment by path (the segment is
created/updated by the sidecar at an arbitrary later time), so it relies on the
lazy-reopen behaviour. The fix mirrors libdatadog's own usage for the analogous
named-segment reader (datadog-sidecar/src/service/agent_info.rs:191):

let reader = OneWayShmReader::<NamedShmHandle, _>::new_with_opener(
    open_named_shm(&shm_path).ok(),
    shm_path,
    |path| open_named_shm(path).ok(),
);

shm_path is the CString returned by path_for_telemetry, matching the
opener signature fn(&D) -> Option<MappedMem<T>> (here &CString derefs to the
&CStr accepted by open_named_shm). The use import path
(datadog_ipc::one_way_shared_memory::{open_named_shm, OneWayShmReader}) is
unchanged and still resolves after the IPC extraction.

This preserves the original semantics (initial best-effort map, lazy reopen on
later reads) rather than the Option::expect panic the compiler suggested, which
would crash if the sidecar had not yet created the segment.

Identified libdatadog issues

None identified. The signature change is an intentional, documented breaking
refactor with a clear migration path (new_with_opener).

Flaky / ignored failures

None. Every failure is explained by the single compilation error above; no
timing/race/flaky or unrelated infrastructure failures were observed in the
traces.

---

/cc @bwoebi

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f826cc728b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Regenerate the sidecar FFI signature

This libdatadog bump changes ddog_sidecar_session_set_config by inserting retry_interval_milliseconds after flush_interval_milliseconds, but the checked-in components-rs/sidecar.h and the call in ext/sidecar.c still use the old argument list. Because C compiles against the stale header, this will not be caught at compile time; at runtime the new Rust FFI function will read every argument after the flush interval in the wrong slot, so normal sidecar startup can misconfigure intervals/sizes and eventually interpret non-pointer values as strings or callbacks. Please regenerate/update the header and pass the new retry interval at the call site as part of this bump.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Handle invalid flag configs as defaults

The new libdatadog revision also adds EvaluationError::FlagConfigurationInvalid, which get_assignment can return for a requested flag whose per-flag config is invalid/unsupported; upstream FFE FFI maps that case to DEFAULT with no error so callers get their supplied default. This wrapper only added the new assignment reason, while the error match below still sends the new error through _ => (ERROR_GENERAL, REASON_ERROR), so those flags will now surface as evaluation errors instead of default evaluations. Please add an explicit arm for the new error variant.

Useful? React with 👍 / 👎.

[datadog-prod-us1-3]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 4 Pipeline jobs failed

Profiling ASAN/UBSAN Tests | PHP 8.5 zts UBSAN (arm-8core-linux)     

DataDog/apm-reliability/dd-trace-php | package-oci: [linux, arm64]     

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [8.4]     

View all 4 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 54.08% (-0.02%)

Useful? React with 👍 / 👎

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

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-06-19 13:49:15

Comparing candidate commit 155c2a9 in PR branch bot/libdatadog-latest with baseline commit b21cc23 in branch master.

Found 3 performance improvements and 0 performance regressions! Performance is the same for 191 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:ComposerTelemetryBench/benchTelemetryParsing-opcache

• 🟩 execution_time [-1.830µs; -0.370µs] or [-10.341%; -2.088%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1-opcache

• 🟩 execution_time [-611.458ns; -379.142ns] or [-4.896%; -3.036%]

scenario:SamplingRuleMatchingBench/benchRegexMatching3-opcache

• 🟩 execution_time [-573.417ns; -273.783ns] or [-4.616%; -2.204%]