Skip to content

feat(sidecar)!: V1 trace builder and send FFI for tracers - #2311

Draft
Leiyks wants to merge 3 commits into
mainfrom
leiyks/v1-sidecar-send-ffi
Draft

Leiyks wants to merge 3 commits into
mainfrom
leiyks/v1-sidecar-send-ffi

Conversation

@Leiyks

@Leiyks Leiyks commented Aug 4, 2026 •

Copy link
Copy Markdown
Contributor

V1 Efficient Trace Payload support for SDKs (dd-trace-php first), on top of the merged v1 encoder (#2145), decoder (#2174) and sidecar transport (#2156). Exercised by DataDog/dd-trace-php#4046, which pins this branch.

  • libdd-trace-utils: SpanKind::Unspecified (0) becomes the default and is left off the V1 wire. TracerPayload::dedup dedups every attribute map, nested ones included (last write wins).
  • v1 to v0.4 downgrade (msgpack_encoder::v04::span_v1), used for agents without /v1.0/traces and for the in-process sender:
    • Span links go to the native span_links field (attributes stringified, nested values as their json_encode string). Span events go to the legacy events meta JSON, since native span_events needs agent 7.63+. Floats in these JSON strings are formatted like PHP's json_encode.
    • Trace-level tags (_dd.p.tid, _dd.origin, _dd.p.dm, _sampling_priority_v1) go on the chunk's local root only.
    • Payload attributes apply to every span with the lowest precedence (span > chunk > payload), except _dd.tags.process / _dd.sdk.otlp_export (first span of each chunk) and _dd.git.* (local root), as pre-V1 tracers wrote them.
    • A dropped_trace chunk keeps its own priority and only defaults to -1 when it has none.
  • datadog-sidecar: send_trace_v1_* sends V1 when the session's /info advertises /v1.0/traces (or in agentless mode), otherwise it downgrades to v0.4 and re-decodes. It fails closed to v0.4 until /info is known, and the force_v04_traces session option skips V1 entirely. The sidecar does not compute top-level spans: the tracer marks _dd.top_level and sets client_computed_top_level, and the sidecar warns when a V1 chunk has no top-level span.
  • datadog-sidecar-ffi: a V1 payload builder with Box-per-node pointer handles (chunks, spans, links, events, attribute maps), so no &mut borrow crosses the FFI and no index is re-fetched. It comes with read-back getters, ddog_send_traces_to_sidecar_v1, ddog_sidecar_send_trace_v1_{shm,bytes} and ddog_downgrade_v1_builder_to_v04_traces (for the in-process sender). The v0.4 span builder FFI is removed; only the TracesBytes collection used as the downgrade target remains (span_v04.rs).

The !: ddog_sidecar_session_set_config takes a new force_v04_traces argument, the v0.4 span builder FFI is replaced by the V1 one (ddog_set_span_* now take V1 span handles), and the SpanKind default changes from Internal to Unspecified.

@github-actions

github-actions Bot commented Aug 4, 2026 •

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 7854 documentation warning(s) found

📦 datadog-sidecar-ffi - 3212 warning(s)

📦 datadog-sidecar - 2939 warning(s)

📦 libdd-trace-stats - 925 warning(s)

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


Updated: 2026-10-01 17:00:27 UTC | Commit: e1d9b69 | missing-docs job results

@github-actions

github-actions Bot commented Aug 4, 2026 •

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 datadog-sidecar-ffi - 4 error(s)

Show output
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     │   └── datadog-sidecar-ffi v0.0.1
     ├── (dev) libdd-ffe v2.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v2.0.0
         ├── datadog-sidecar v0.0.1 (*)
         └── datadog-sidecar-ffi v0.0.1 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:232:1
    │
232 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v2.0.0
          └── datadog-sidecar v0.0.1
              └── datadog-sidecar-ffi v0.0.1

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:275:1
    │
275 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2024-0436
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
    ├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md) 
      that this project is not longer maintained as well as archived the repository
      
      ## Possible Alternative(s)
      
      - [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
      - [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros
      
      [`pastey`]: https://crates.io/crates/pastey
      [`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros
    ├ Announcement: https://github.com/dtolnay/paste
    ├ Solution: No safe upgrade is available!
    ├ paste v1.0.15
      ├── libdd-libunwind-sys v1.0.3
      │   └── libdd-crashtracker v3.0.0
      │       ├── datadog-sidecar v0.0.1
      │       │   └── datadog-sidecar-ffi v0.0.1
      │       ├── datadog-sidecar-ffi v0.0.1 (*)
      │       └── libdd-crashtracker-ffi v44.0.0
      │           ├── datadog-sidecar v0.0.1 (*)
      │           └── datadog-sidecar-ffi v0.0.1 (*)
      ├── libdd-telemetry-ffi v44.0.0
      │   └── datadog-sidecar-ffi v0.0.1 (*)
      └── rmp v0.8.14
          ├── libdd-trace-utils v13.0.0
          │   ├── (dev) datadog-sidecar v0.0.1 (*)
          │   ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v11.0.0
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   └── libdd-live-debugger v1.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline-core v2.0.0
          │   │   └── libdd-data-pipeline v11.0.0 (*)
          │   ├── libdd-trace-obfuscation v9.0.0
          │   │   ├── libdd-data-pipeline v11.0.0 (*)
          │   │   ├── libdd-data-pipeline-core v2.0.0 (*)
          │   │   └── libdd-trace-stats v10.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       ├── libdd-data-pipeline v11.0.0 (*)
          │   │       └── libdd-ipc v2.0.0
          │   │           ├── datadog-sidecar v0.0.1 (*)
          │   │           └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-trace-stats v10.0.0 (*)
          │   └── (dev) libdd-trace-utils v13.0.0 (*)
          ├── rmp-serde v1.3.0
          │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v11.0.0 (*)
          │   ├── (dev) libdd-tinybytes v1.1.4
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   │   ├── libdd-data-pipeline v11.0.0 (*)
          │   │   ├── (dev) libdd-data-pipeline-core v2.0.0 (*)
          │   │   ├── libdd-ipc v2.0.0 (*)
          │   │   ├── (dev) libdd-tinybytes v1.1.4 (*)
          │   │   ├── (dev) libdd-trace-obfuscation v9.0.0 (*)
          │   │   └── libdd-trace-utils v13.0.0 (*)
          │   ├── libdd-trace-stats v10.0.0 (*)
          │   └── libdd-trace-utils v13.0.0 (*)
          └── rmpv v1.3.0
              └── libdd-trace-utils v13.0.0 (*)

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:333:1
    │
333 │ 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/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v7.0.0
      │       ├── datadog-sidecar v0.0.1
      │       │   └── datadog-sidecar-ffi v0.0.1
      │       ├── datadog-sidecar-ffi v0.0.1 (*)
      │       ├── libdd-capabilities-impl v6.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   └── libdd-crashtracker-ffi v44.0.0
      │       │   │       ├── datadog-sidecar v0.0.1 (*)
      │       │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │       │   ├── libdd-data-pipeline v11.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   └── libdd-live-debugger v1.0.0
      │       │   │       ├── datadog-sidecar v0.0.1 (*)
      │       │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │       │   ├── (dev) libdd-ffe v2.0.0
      │       │   │   └── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   ├── libdd-remote-config v6.0.0
      │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   ├── libdd-ffe v2.0.0 (*)
      │       │   │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   │   └── (dev) libdd-remote-config v6.0.0 (*)
      │       │   ├── libdd-shared-runtime v5.0.0
      │       │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v7.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v10.0.0
      │       │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │       ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │       └── libdd-ipc v2.0.0
      │       │   │   │           ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │           └── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   ├── libdd-telemetry v9.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   │   ├── libdd-crashtracker v3.0.0 (*)
      │       │   │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │   ├── libdd-telemetry-ffi v44.0.0
      │       │   │   │   │   └── datadog-sidecar-ffi v0.0.1 (*)
      │       │   │   │   └── libdd-trace-stats v10.0.0 (*)
      │       │   │   └── libdd-trace-stats v10.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v9.0.0 (*)
      │       │   ├── libdd-telemetry-ffi v44.0.0 (*)
      │       │   ├── libdd-trace-stats v10.0.0 (*)
      │       │   └── libdd-trace-utils v13.0.0
      │       │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │       ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
      │       │       ├── libdd-data-pipeline v11.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v2.0.0
      │       │       │   └── libdd-data-pipeline v11.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v9.0.0
      │       │       │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v2.0.0 (*)
      │       │       │   └── libdd-trace-stats v10.0.0 (*)
      │       │       ├── libdd-trace-stats v10.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v13.0.0 (*)
      │       ├── libdd-common-ffi v44.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │       │   ├── libdd-crashtracker-ffi v44.0.0 (*)
      │       │   └── libdd-telemetry-ffi v44.0.0 (*)
      │       ├── (build) libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v44.0.0 (*)
      │       ├── libdd-data-pipeline v11.0.0 (*)
      │       ├── libdd-data-pipeline-core v2.0.0 (*)
      │       ├── libdd-dogstatsd-client v7.0.0 (*)
      │       ├── libdd-ffe v2.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-live-debugger v1.0.0 (*)
      │       ├── libdd-remote-config v6.0.0 (*)
      │       ├── libdd-shared-runtime v5.0.0 (*)
      │       ├── libdd-telemetry v9.0.0 (*)
      │       ├── libdd-telemetry-ffi v44.0.0 (*)
      │       ├── libdd-trace-obfuscation v9.0.0 (*)
      │       ├── libdd-trace-stats v10.0.0 (*)
      │       └── libdd-trace-utils v13.0.0 (*)
      ├── libdd-common v7.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v7.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 datadog-sidecar - 3 error(s)

Show output
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     ├── (dev) libdd-ffe v2.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v2.0.0
         └── datadog-sidecar v0.0.1 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v2.0.0
          └── datadog-sidecar v0.0.1

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:331:1
    │
331 │ 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/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v7.0.0
      │       ├── datadog-sidecar v0.0.1
      │       ├── libdd-capabilities-impl v6.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   └── libdd-crashtracker-ffi v44.0.0
      │       │   │       └── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-data-pipeline v11.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   └── libdd-live-debugger v1.0.0
      │       │   │       └── datadog-sidecar v0.0.1 (*)
      │       │   ├── (dev) libdd-ffe v2.0.0
      │       │   │   └── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   ├── libdd-remote-config v6.0.0
      │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │   │   ├── libdd-ffe v2.0.0 (*)
      │       │   │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   │   └── (dev) libdd-remote-config v6.0.0 (*)
      │       │   ├── libdd-shared-runtime v5.0.0
      │       │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v7.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v10.0.0
      │       │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │       ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │       └── libdd-ipc v2.0.0
      │       │   │   │           └── datadog-sidecar v0.0.1 (*)
      │       │   │   ├── libdd-telemetry v9.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── libdd-crashtracker v3.0.0 (*)
      │       │   │   │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v10.0.0 (*)
      │       │   │   └── libdd-trace-stats v10.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v9.0.0 (*)
      │       │   ├── libdd-trace-stats v10.0.0 (*)
      │       │   └── libdd-trace-utils v13.0.0
      │       │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │       ├── libdd-data-pipeline v11.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v2.0.0
      │       │       │   └── libdd-data-pipeline v11.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v9.0.0
      │       │       │   ├── libdd-data-pipeline v11.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v2.0.0 (*)
      │       │       │   └── libdd-trace-stats v10.0.0 (*)
      │       │       ├── libdd-trace-stats v10.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v13.0.0 (*)
      │       ├── libdd-common-ffi v44.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   └── libdd-crashtracker-ffi v44.0.0 (*)
      │       ├── (build) libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v44.0.0 (*)
      │       ├── libdd-data-pipeline v11.0.0 (*)
      │       ├── libdd-data-pipeline-core v2.0.0 (*)
      │       ├── libdd-dogstatsd-client v7.0.0 (*)
      │       ├── libdd-ffe v2.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-live-debugger v1.0.0 (*)
      │       ├── libdd-remote-config v6.0.0 (*)
      │       ├── libdd-shared-runtime v5.0.0 (*)
      │       ├── libdd-telemetry v9.0.0 (*)
      │       ├── libdd-trace-obfuscation v9.0.0 (*)
      │       ├── libdd-trace-stats v10.0.0 (*)
      │       └── libdd-trace-utils v13.0.0 (*)
      ├── libdd-common v7.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v7.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-stats - 1 error(s)

Show output
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:222:1
    │
222 │ 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/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v7.0.0
      │       ├── libdd-capabilities-impl v6.0.0
      │       │   ├── libdd-shared-runtime v5.0.0
      │       │   │   ├── libdd-telemetry v9.0.0
      │       │   │   │   └── libdd-trace-stats v10.0.0
      │       │   │   └── libdd-trace-stats v10.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v9.0.0 (*)
      │       │   ├── libdd-trace-stats v10.0.0 (*)
      │       │   └── libdd-trace-utils v13.0.0
      │       │       ├── libdd-trace-obfuscation v9.0.0
      │       │       │   └── libdd-trace-stats v10.0.0 (*)
      │       │       ├── libdd-trace-stats v10.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v13.0.0 (*)
      │       ├── libdd-dogstatsd-client v7.0.0
      │       │   └── libdd-trace-stats v10.0.0 (*)
      │       ├── libdd-shared-runtime v5.0.0 (*)
      │       ├── libdd-telemetry v9.0.0 (*)
      │       ├── libdd-trace-obfuscation v9.0.0 (*)
      │       ├── libdd-trace-stats v10.0.0 (*)
      │       └── libdd-trace-utils v13.0.0 (*)
      ├── libdd-common v7.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v7.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

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

Show output
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:206:1
    │
206 │ 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/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v7.0.0
      │       ├── libdd-capabilities-impl v6.0.0
      │       │   └── libdd-trace-utils v13.0.0
      │       │       └── (dev) libdd-trace-utils v13.0.0 (*)
      │       └── libdd-trace-utils v13.0.0 (*)
      ├── libdd-common v7.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v7.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-10-01 17:00:37 UTC | Commit: e1d9b69 | dependency-check job results

@datadog-prod-us1-6

datadog-prod-us1-6 Bot commented Aug 4, 2026 •

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

Required checks pass | allchecks

View more details · View in GitHub Actions

Test | cargo test #windows-latest

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: 81.06%
• Overall Coverage: 80.15% (+0.04%)

Useful? React with 👍 / 👎

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

@dd-octo-sts

dd-octo-sts Bot commented Aug 4, 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.so 9.08 MB 9.08 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 96.60 MB 96.61 MB +0% (+7.23 KB) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 107.95 MB 107.95 MB +0% (+5.15 KB) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.27 MB 12.27 MB +0% (+56 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 29.09 MB 29.09 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 97.94 KB 97.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 191.84 MB 191.85 MB +0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 819.40 MB 819.40 MB -0% (-3.53 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.76 MB 9.76 MB +.01% (+1.00 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 97.94 KB 97.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 27.60 MB 27.60 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 55.79 MB 55.79 MB +0% (+5.21 KB) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 25.51 MB 25.51 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 99.47 KB 99.47 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 197.49 MB 197.48 MB -0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 803.88 MB 804.22 MB +.04% (+354.65 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.57 MB 7.57 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 99.47 KB 99.47 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 29.71 MB 29.73 MB +.05% (+16.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 52.72 MB 52.72 MB +0% (+3.25 KB) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 86.50 MB 86.51 MB +0% (+6.71 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.11 MB 10.11 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.38 MB 102.38 MB +0% (+6.67 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.35 MB 12.35 MB +0% (+88 B) 👌

@pr-commenter

pr-commenter Bot commented Aug 5, 2026 •

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-10-01 17:26:09

Comparing candidate commit 89d5b1f in PR branch leiyks/v1-sidecar-send-ffi with baseline commit e35a4f9 in branch main.

📊 Benchmarking dashboard

Found 2 performance improvements and 2 performance regressions! Performance is the same for 125 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:msgpack_decoder::v05/high_sharing/200

  • 🟥 execution_time [+12.719µs; +12.800µs] or [+8.045%; +8.096%]
  • 🟥 throughput [-94782.942op/s; -94165.166op/s] or [-7.492%; -7.444%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

  • 🟩 execution_time [-16.463ns; -16.091ns] or [-4.463%; -4.362%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_2/8

  • 🟩 execution_time [-21.805ns; -21.502ns] or [-4.509%; -4.446%]

Benchmark execution time: 2026-10-01 17:24:48

Comparing candidate commit 89d5b1f in PR branch leiyks/v1-sidecar-send-ffi with baseline commit e35a4f9 in branch main.

📊 Benchmarking dashboard

Found 3 performance improvements and 4 performance regressions! Performance is the same for 101 metrics, 10 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:datadog_sample_span/unicode_uppercase_service_rule/wall_time

  • 🟥 execution_time [+15.065ns; +15.223ns] or [+4.354%; +4.400%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

  • 🟩 execution_time [-1.921ns; -1.805ns] or [-6.454%; -6.063%]

scenario:glob_matcher/ascii_exact_match/wall_time

  • 🟩 execution_time [-1.908ns; -1.792ns] or [-6.412%; -6.019%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/wall_time

  • 🟥 execution_time [+4.052ns; +4.096ns] or [+9.916%; +10.023%]

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

  • 🟩 execution_time [-5.173ns; -5.107ns] or [-5.423%; -5.354%]

scenario:trace_buffer/4_senders/no_delay

  • 🟥 execution_time [+115.062µs; +157.401µs] or [+5.296%; +7.245%]
  • 🟥 throughput [-119844.963op/s; -87414.642op/s] or [-7.202%; -5.253%]

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/parent_not_sampled_short_circuit/allocated_bytes

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

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

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

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

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

scenario:glob_matcher/ascii_exact_match/allocated_bytes

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

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

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

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

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

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

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

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

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

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

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

scenario:glob_matcher/star_short_circuit/allocated_bytes

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

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from 19675f4 to d81d005 Compare August 6, 2026 12:33
@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from d81d005 to e12dbe1 Compare August 24, 2026 15:26
Base automatically changed from anais/sidecar-from-v04-to-v1-span to main August 25, 2026 14:09
@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from e12dbe1 to c5dc301 Compare August 25, 2026 15:32
@Leiyks
Leiyks marked this pull request as ready for review August 26, 2026 11:56
@Leiyks
Leiyks requested review from a team as code owners August 26, 2026 11:56

@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: c5dc30175f

ℹ️ 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 thread datadog-sidecar-ffi/src/lib.rs Outdated
.into_owned(),
git_commit_sha: self.git_commit_sha.to_utf8_lossy().into_owned(),
process_tags: self.process_tags.to_utf8_lossy().into_owned(),
..Default::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.

P2 Badge Preserve the container ID in V1 metadata

When a tracer supplies parameters.tracer_headers_tags.container_id, this conversion leaves TracerMetadata::container_id at its empty default. The V1 encoder consequently omits the container-ID payload key (msgpack_encoder/v1/mod.rs:338,372-374), and the sidecar reconstructs the outgoing Datadog-Container-Id header exclusively from that decoded field (sidecar_server.rs:317-325), so all traces sent through this new high-level API lose their container attribution. Populate this field from the existing header tags or expose it in TracerMetadataV1.

Useful? React with 👍 / 👎.

@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from 53437b3 to 6e09e18 Compare September 1, 2026 12:22
@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from 3582ada to 382b667 Compare September 15, 2026 11:45
@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from d87243e to 5f966b2 Compare September 29, 2026 16:10
@Leiyks Leiyks changed the title feat(sidecar): high-level v1 encode+send FFI for tracers feat(sidecar)!: high-level v1 encode+send FFI for tracers Sep 30, 2026
/// dropped (the tracer never emits them for links).
/// * `dropped_attributes_count` / `flags` — not part of the legacy shape (master leaves the count
/// property unset; flags is a native-only concept).
fn span_links_to_legacy_json<T: TraceData>(span_links: &[SpanLink<T>]) -> String {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

msgpack span_links v04 is old enough to just support, we don't need json here.

Comment thread libdd-trace-utils/src/tracer_payload.rs Outdated
})?;
// V1 attributes are flat triplets that may repeat keys, so the decoder leaves the maps
// un-deduped; dedup once here so re-encoding doesn't take the warning fallback.
data.dedup();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should audit the amount of dedups again across everything, because they're expensive to do repeatedly.

Comment on lines +397 to +406
if supports_v1 {
if let TraceChunks::V1(p) = &mut payload {
if !generic.client_computed_top_level {
for chunk in &mut p.chunks {
trace_utils_v1::compute_tracer_top_level_span(&mut chunk.spans);
}
}
}
generic.client_computed_top_level = true;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This should be handled in the tracer. (which just knows what the top level span is and doesn't have to compute it)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe add a warn!() or something if it's not set.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

You added... actual v1 functions into the test code to test them, without ... exposing it?!

Comment thread datadog-sidecar-ffi/src/span.rs Outdated
Comment on lines +483 to +485
builder: &TracerPayloadV1Builder,
chunk: usize,
span: usize,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Like in dd-trace-php, avoid the index-indirection, it's slow.

Comment thread libdd-trace-utils/src/span/vec_map.rs Outdated
Comment on lines +43 to +44
/// insertion order, and [Self::dedup] preserves it: a duplicate key's surviving (last-written)
/// entry keeps the position of that last write, earlier duplicates are simply dropped.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why this change? Is the insertion order actually important?

Leiyks added 3 commits October 1, 2026 17:20
Extend the native v1 span model with payload-level attributes, unspecified span kind and tracer-marked top-level spans. Make the v1 to v0.4 downgrade self-contained: legacy _dd.span_links/_dd.span_events meta for old agents, PHP-compatible JSON float formatting, chunk-root rules shared with v1, and process tags on each trace's first span. Dedup V1 payloads after decoding and keep insertion order in VecMap.
Send traces to the agent as v1 when /info advertises /v1.0/traces and downgrade to v0.4 otherwise, using the session's /info for the first send. Tracer-marked top-level spans are honoured in the sidecar.
Add the V1 trace builder FFI (Box-per-node pointer handles for chunks, spans, links, events and attribute maps), ddog_send_traces_to_sidecar_v1, and the v04-to-v1 transcode used by the in-process sender. Shrink ddog_TracerMetadataV1.
@Leiyks
Leiyks force-pushed the leiyks/v1-sidecar-send-ffi branch from 3093805 to 89d5b1f Compare October 1, 2026 16:56
@Leiyks Leiyks changed the title feat(sidecar)!: high-level v1 encode+send FFI for tracers feat(sidecar)!: V1 trace builder and send FFI for tracers Oct 1, 2026

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.

2 participants