Skip to content

feat(libdd-data-pipeline-ffi): add ddog_trace_exporter_builder_* FFI mirroring the Rust builder - #2689

Open
VianneyRuhlmann wants to merge 2 commits into
mainfrom
vianney/remove-config-in-ffi
Open

VianneyRuhlmann wants to merge 2 commits into
mainfrom
vianney/remove-config-in-ffi

Conversation

@VianneyRuhlmann

@VianneyRuhlmann VianneyRuhlmann commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Summary

This PR deprecates the intermediate config struct in libdd-data-pipeline-ffi to expose the builder directly removing discrepancies in the setters and reduces the drift between the native api and the ffi api.

Key points

  • Ownership semantics: ddog_trace_exporter_builder_build consumes the builder, including on build failure; legacy ddog_trace_exporter_new still leaves the config with the caller.
  • Enable-only semantics for health metrics, stats, and client-computed stats/headers, per review feedback; enable_stats takes a bucket interval in seconds (10 = default).
  • New C types: ddog_ExporterTelemetryConfig (2 fields), ddog_ExporterTagList, ddog_ExporterHeader/ddog_ExporterHeaderList for the Vec-based builder methods. Telemetry enable and instrumentation-sessions are separate bindings (no more 2-in-1).
  • Name mapping follows the builder, not the legacy FFI: set_lang_version→set_language_version, set_version→set_app_version, set_compute_stats→enable_stats, etc.
  • Parity: 47 of 51 builder methods bound. build_async is not representable over C FFI. The three feature-gated methods are excluded here — cbindgen does not evaluate #[cfg], so gated bindings would be declared in the default header while missing from the compiled library: two stats-obfuscation-gated methods are added in a stacked PR that makes the feature default-on; enable_observations (external-observations) is likewise deferred to a follow-up that resolves its feature gating.
  • examples/ffi/trace_exporter.c migrated to the builder API.

Validation

cargo check, clippy -D warnings, doctests, pinned-nightly fmt, 189 tests across the changed crates (MSRV 1.87 and stable, with external-observations enabled), full cargo ffi-test (12 pass; ffe fails on a pre-existing missing fixture, identical on main). Both C API paths (builder + unchanged legacy example from main) compile and run.

Notes for reviewers

  • SDK consumers pin libdatadog versions; deprecation is informational until each SDK migrates.
  • Consumers building with -Werror=deprecated-declarations must suppress or migrate.

@github-actions

github-actions Bot commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 1422 documentation warning(s) found

📦 libdd-data-pipeline-ffi - 1422 warning(s)


Updated: 2026-11-09 20:19:56 UTC | Commit: 7bbfad7 | missing-docs job results

@github-actions

github-actions Bot commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 libdd-data-pipeline-ffi - 5 error(s)

Show output
info: syncing channel updates for 1.91.1-x86_64-unknown-linux-gnu
info: latest update on 2025-11-10 for version 1.91.1 (ed61e7d7e 2025-11-07)
info: downloading 6 components
warn: the missing active toolchain `1.91.1-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:255:1
    │
255 │ 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 v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-data-pipeline v13.0.0
      │       │   │   └── libdd-data-pipeline-ffi v48.0.0
      │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v9.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0
      │       │   │   │       └── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-telemetry v11.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v11.0.0 (*)
      │       │   ├── libdd-trace-stats v12.0.0 (*)
      │       │   └── libdd-trace-utils v15.0.0
      │       │       ├── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v4.0.0
      │       │       │   └── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v11.0.0
      │       │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v4.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       │   └── libdd-trace-stats v12.0.0 (*)
      │       │       ├── libdd-trace-stats v12.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v15.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-data-pipeline v13.0.0 (*)
      │       ├── libdd-data-pipeline-core v4.0.0 (*)
      │       ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-dogstatsd-client v9.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       ├── libdd-telemetry v11.0.0 (*)
      │       ├── libdd-trace-obfuscation v11.0.0 (*)
      │       ├── libdd-trace-stats v12.0.0 (*)
      │       └── libdd-trace-utils v15.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ 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 v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-data-pipeline v13.0.0
      │       │   │   └── libdd-data-pipeline-ffi v48.0.0
      │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v9.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0
      │       │   │   │       └── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-telemetry v11.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v11.0.0 (*)
      │       │   ├── libdd-trace-stats v12.0.0 (*)
      │       │   └── libdd-trace-utils v15.0.0
      │       │       ├── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v4.0.0
      │       │       │   └── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v11.0.0
      │       │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v4.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       │   └── libdd-trace-stats v12.0.0 (*)
      │       │       ├── libdd-trace-stats v12.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v15.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-data-pipeline v13.0.0 (*)
      │       ├── libdd-data-pipeline-core v4.0.0 (*)
      │       ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-dogstatsd-client v9.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       ├── libdd-telemetry v11.0.0 (*)
      │       ├── libdd-trace-obfuscation v11.0.0 (*)
      │       ├── libdd-trace-stats v12.0.0 (*)
      │       └── libdd-trace-utils v15.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ 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 v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-data-pipeline v13.0.0
      │       │   │   └── libdd-data-pipeline-ffi v48.0.0
      │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v9.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0
      │       │   │   │       └── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-telemetry v11.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v11.0.0 (*)
      │       │   ├── libdd-trace-stats v12.0.0 (*)
      │       │   └── libdd-trace-utils v15.0.0
      │       │       ├── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v4.0.0
      │       │       │   └── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v11.0.0
      │       │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v4.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       │   └── libdd-trace-stats v12.0.0 (*)
      │       │       ├── libdd-trace-stats v12.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v15.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-data-pipeline v13.0.0 (*)
      │       ├── libdd-data-pipeline-core v4.0.0 (*)
      │       ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-dogstatsd-client v9.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       ├── libdd-telemetry v11.0.0 (*)
      │       ├── libdd-trace-obfuscation v11.0.0 (*)
      │       ├── libdd-trace-stats v12.0.0 (*)
      │       └── libdd-trace-utils v15.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ 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 v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-data-pipeline v13.0.0
      │       │   │   └── libdd-data-pipeline-ffi v48.0.0
      │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v9.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0
      │       │   │   │       └── libdd-data-pipeline v13.0.0 (*)
      │       │   │   ├── libdd-telemetry v11.0.0
      │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   │   └── libdd-trace-stats v12.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v11.0.0 (*)
      │       │   ├── libdd-trace-stats v12.0.0 (*)
      │       │   └── libdd-trace-utils v15.0.0
      │       │       ├── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v4.0.0
      │       │       │   └── libdd-data-pipeline v13.0.0 (*)
      │       │       ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v11.0.0
      │       │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v4.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       │       │   └── libdd-trace-stats v12.0.0 (*)
      │       │       ├── libdd-trace-stats v12.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v15.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-data-pipeline v13.0.0 (*)
      │       ├── libdd-data-pipeline-core v4.0.0 (*)
      │       ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │       ├── libdd-dogstatsd-client v9.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       ├── libdd-telemetry v11.0.0 (*)
      │       ├── libdd-trace-obfuscation v11.0.0 (*)
      │       ├── libdd-trace-stats v12.0.0 (*)
      │       └── libdd-trace-utils v15.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:316:1
    │
316 │ 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
      │   │   │   ├── (dev) libdd-data-pipeline v13.0.0
      │   │   │   │   └── libdd-data-pipeline-ffi v48.0.0
      │   │   │   ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │   ├── (dev) libdd-telemetry v11.0.0
      │   │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v12.0.0
      │   │   │   │       └── libdd-data-pipeline v13.0.0 (*)
      │   │   │   ├── (dev) libdd-trace-stats v12.0.0 (*)
      │   │   │   └── libdd-trace-utils v15.0.0
      │   │   │       ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       ├── libdd-data-pipeline-core v4.0.0
      │   │   │       │   └── libdd-data-pipeline v13.0.0 (*)
      │   │   │       ├── (dev) libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       ├── libdd-trace-obfuscation v11.0.0
      │   │   │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       │   ├── libdd-data-pipeline-core v4.0.0 (*)
      │   │   │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       │   └── libdd-trace-stats v12.0.0 (*)
      │   │   │       ├── libdd-trace-stats v12.0.0 (*)
      │   │   │       └── (dev) libdd-trace-utils v15.0.0 (*)
      │   │   ├── hyper-rustls v0.27.7
      │   │   │   └── libdd-common v9.0.0
      │   │   │       ├── libdd-capabilities-impl v8.0.0
      │   │   │       │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       │   ├── libdd-shared-runtime v7.0.0
      │   │   │       │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       │   │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       │   │   ├── libdd-dogstatsd-client v9.0.0
      │   │   │       │   │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       │   │   │   └── libdd-trace-stats v12.0.0 (*)
      │   │   │       │   │   ├── libdd-telemetry v11.0.0 (*)
      │   │   │       │   │   └── libdd-trace-stats v12.0.0 (*)
      │   │   │       │   ├── (dev) libdd-telemetry v11.0.0 (*)
      │   │   │       │   ├── libdd-trace-stats v12.0.0 (*)
      │   │   │       │   └── libdd-trace-utils v15.0.0 (*)
      │   │   │       ├── libdd-common-ffi v48.0.0
      │   │   │       │   └── libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       ├── libdd-data-pipeline v13.0.0 (*)
      │   │   │       ├── libdd-data-pipeline-core v4.0.0 (*)
      │   │   │       ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │   │   │       ├── libdd-dogstatsd-client v9.0.0 (*)
      │   │   │       ├── libdd-shared-runtime v7.0.0 (*)
      │   │   │       ├── libdd-telemetry v11.0.0 (*)
      │   │   │       ├── libdd-trace-obfuscation v11.0.0 (*)
      │   │   │       ├── libdd-trace-stats v12.0.0 (*)
      │   │   │       └── libdd-trace-utils v15.0.0 (*)
      │   │   ├── hyper-util v0.1.17
      │   │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   │   ├── libdd-common v9.0.0 (*)
      │   │   │   └── libdd-data-pipeline v13.0.0 (*)
      │   │   ├── libdd-common v9.0.0 (*)
      │   │   ├── libdd-common-ffi v48.0.0 (*)
      │   │   ├── libdd-data-pipeline v13.0.0 (*)
      │   │   └── libdd-trace-utils v15.0.0 (*)
      │   └── (dev) libdd-data-pipeline v13.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 v8.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v13.0.0 (*)
      ├── (dev) libdd-dogstatsd-client v9.0.0 (*)
      ├── libdd-shared-runtime v7.0.0 (*)
      ├── (dev) libdd-telemetry v11.0.0 (*)
      ├── (dev) libdd-trace-protobuf v5.1.1
      │   ├── libdd-data-pipeline v13.0.0 (*)
      │   ├── libdd-trace-normalization v4.3.0
      │   │   └── libdd-trace-utils v15.0.0 (*)
      │   ├── libdd-trace-obfuscation v11.0.0 (*)
      │   ├── libdd-trace-stats v12.0.0 (*)
      │   └── libdd-trace-utils v15.0.0 (*)
      ├── (dev) libdd-trace-stats v12.0.0 (*)
      ├── libdd-trace-utils v15.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   ├── hyper-rustls v0.27.7 (*)
      │   └── (dev) libdd-common v9.0.0 (*)
      ├── tokio-stream v0.1.16
      │   └── tonic v0.14.2
      │       └── libdd-data-pipeline v13.0.0 (*)
      ├── tokio-util v0.7.12
      │   ├── h2 v0.4.19 (*)
      │   ├── libdd-data-pipeline v13.0.0 (*)
      │   ├── libdd-data-pipeline-ffi v48.0.0 (*)
      │   └── libdd-telemetry v11.0.0 (*)
      └── (dev) tools v48.0.0
          ├── (dev) libdd-common v9.0.0 (*)
          ├── (dev) libdd-telemetry v11.0.0 (*)
          └── (dev) libdd-trace-utils v15.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-11-09 20:20:56 UTC | Commit: 7bbfad7 | dependency-check job results

@datadog-official

datadog-official Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Pipelines  Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 86.33%
• Overall Coverage: 81.42% (-2.26%)

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

@pr-commenter

pr-commenter Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Benchmarks

Comparison

Candidate

Candidate benchmark details

Baseline

Baseline benchmark details

…mirroring the Rust builder

Add a ddog_trace_exporter_builder_* FFI that maps 1:1 onto
TraceExporterBuilder, alongside the existing ddog_trace_exporter_config_*
API which is now deprecated (Rust #[deprecated] plus a portable
DDOG_TRACE_EXPORTER_DEPRECATED macro in the generated header; behavior
unchanged).

- enable-only setters for health metrics, stats and client-computed
  stats/headers; enable_stats takes a bucket interval in seconds
- ddog_trace_exporter_builder_build consumes the builder, including on
  error
- new C types: ddog_ExporterTelemetryConfig (2 fields),
  ddog_ExporterTagList, ddog_ExporterHeader(List) for Vec-based builder
  methods; telemetry enable and instrumentation sessions are separate
  bindings
- parity: 47 of 48 builder methods bound (build_async is not
  representable; the 2 stats-obfuscation-gated ones are excluded because
  cbindgen does not evaluate #[cfg])
- migrate examples/ffi/trace_exporter.c to the builder API
@VianneyRuhlmann
VianneyRuhlmann force-pushed the vianney/remove-config-in-ffi branch from f85766e to 4f7d8c3 Compare October 19, 2026 12:47
@dd-octo-sts

dd-octo-sts Bot commented Oct 19, 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 96.74 MB 97.59 MB +.88% (+871.96 KB) 🔍
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 9.21 MB 9.34 MB +1.39% (+131.35 KB) ⚠️
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.46 MB 12.59 MB +1.02% (+130.87 KB) ⚠️
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 107.90 MB 108.77 MB +.80% (+886.10 KB) 🔍
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 29.76 MB 30.02 MB +.88% (+271.00 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 100.25 KB 118.22 KB +17.91% (+17.96 KB) 🚨
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 193.58 MB 194.44 MB +.44% (+880.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 806.90 MB 809.31 MB +.29% (+2.40 MB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.79 MB 9.92 MB +1.42% (+143.00 KB) ⚠️
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 100.25 KB 118.22 KB +17.91% (+17.96 KB) 🚨
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 27.90 MB 28.16 MB +.92% (+264.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 56.08 MB 56.71 MB +1.10% (+636.79 KB) ⚠️
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 26.25 MB 26.49 MB +.94% (+253.50 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 101.81 KB 120.01 KB +17.87% (+18.19 KB) 🚨
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 199.40 MB 200.29 MB +.44% (+912.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 790.67 MB 791.43 MB +.09% (+774.07 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.54 MB 7.64 MB +1.35% (+104.50 KB) ⚠️
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 101.81 KB 120.01 KB +17.87% (+18.19 KB) 🚨
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 29.99 MB 30.27 MB +.93% (+288.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 52.94 MB 53.52 MB +1.08% (+590.46 KB) ⚠️
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 87.21 MB 88.00 MB +.91% (+817.84 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.06 MB 10.18 MB +1.19% (+123.34 KB) ⚠️
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.90 MB 103.72 MB +.78% (+832.29 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.32 MB 12.48 MB +1.35% (+170.36 KB) ⚠️

@VianneyRuhlmann
VianneyRuhlmann marked this pull request as ready for review November 9, 2026 20:18
@VianneyRuhlmann
VianneyRuhlmann requested review from a team as code owners November 9, 2026 20:18
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Nov 9, 2026 •

Copy link
Copy Markdown
Codex Review Summary: ✅ Completed

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

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-11-09T20:23:49.943451Z 0a0a7e9 Draft marked ready
🔒 Security Review ✅ Completed 2026-11-09T20:22:11.629174Z 0a0a7e9 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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0a0a7e9468

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +141 to +144
pub unsafe extern "C" fn ddog_trace_exporter_builder_free(
handle: Box<TraceExporterBuilder<ForkSafeRuntime>>,
) {
drop(handle);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Contain unwinds while freeing builders

Wrap this drop in catch_panic! (or add a justified panic-boundary allowance only if the entire destructor chain is proven panic-free). A builder may own nontrivial state such as the last ForkSafeRuntime reference, so if destruction unwinds, the panic currently crosses the extern "C" boundary and aborts the embedding process instead of being contained.

AGENTS.md reference: AGENTS.md:L102-L103

Useful? React with 👍 / 👎.

Comment on lines +408 to +414
pub unsafe extern "C" fn ddog_trace_exporter_builder_enable_stats(
builder: Option<&mut TraceExporterBuilder<ForkSafeRuntime>>,
bucket_interval_secs: u64,
) -> Option<Box<ExporterError>> {
catch_panic!(
if let Option::Some(builder) = builder {
builder.enable_stats(Duration::from_secs(bucket_interval_secs));

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Reject zero-length stats buckets

Reject bucket_interval_secs == 0 rather than storing Duration::ZERO. When OTLP metrics are configured, build immediately constructs a SpanConcentrator, whose timestamp alignment performs modulo by the bucket size and therefore panics; on the agent path the same panic occurs later when the agent enables client-side stats. Thus an accepted C input can make exporter construction return a panic error or prevent stats from starting instead of returning a clear invalid-argument error here.

AGENTS.md reference: AGENTS.md:L95-L98

Useful? React with 👍 / 👎.

Comment on lines +700 to +703
#[unsafe(no_mangle)]
pub unsafe extern "C" fn ddog_trace_exporter_builder_default_stats_cardinality_limit()
-> CardinalityLimitConfig {
CardinalityLimitConfig::default()

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Acknowledge containment on the default-config accessor

Wrap this new exported accessor with catch_panic!, or place the required justified allow(ffi-panic-boundary) comment directly above it if CardinalityLimitConfig::default is intentionally treated as panic-free. As written, this is an unacknowledged extern "C" boundary, so a future panic introduced anywhere in the default implementation would unwind across C and abort the host process.

AGENTS.md reference: AGENTS.md:L102-L103

Useful? React with 👍 / 👎.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant