chore: implement otel process ctx update#1640
chore: implement otel process ctx update#1640gh-worker-dd-mergequeue-cf854d[bot] merged 13 commits intomainfrom
Conversation
d47aa19 to
9f7f1ff
Compare
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
BenchmarksComparisonBenchmark execution time: 2026-03-04 14:46:01 Comparing candidate commit 1b08e39 in PR branch Found 0 performance improvements and 2 performance regressions! Performance is the same for 55 metrics, 2 unstable metrics. scenario:credit_card/is_card_number/ 378282246310005
CandidateCandidate benchmark detailsGroup 1
Group 2
Group 3
Group 4
Group 5
Group 6
Group 7
Group 8
Group 9
Group 10
Group 11
Group 12
Group 13
Group 14
Group 15
Group 16
Group 17
Group 18
Group 19
BaselineOmitted due to size. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1640 +/- ##
==========================================
+ Coverage 71.19% 71.24% +0.04%
==========================================
Files 425 425
Lines 62666 62705 +39
==========================================
+ Hits 44615 44673 +58
+ Misses 18051 18032 -19
🚀 New features to boost your workflow:
|
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
921f74c to
03052b6
Compare
588ed19 to
28f4c58
Compare
e9fc1af to
b6d62d9
Compare
a7df237 to
1a357fc
Compare
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🔗 Commit SHA: 1b08e39 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
1a357fc to
edaa4df
Compare
ivoanjo
left a comment
There was a problem hiding this comment.
👍 Left a few notes/questions but overall it LGTM, excited for the next parts!
Co-authored-by: Björn Antonsson <bjorn.antonsson@datadoghq.com>
Replace the separate `publish_then_read_context` and `update_process_context` tests with a single `publish_then_update_process_context` test that checks all header fields (signature, version, payload size, timestamp, payload content) after the initial publish of `payload_v1`, then again after the update to `payload_v2`. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace the hand-rolled `TEST_SERIALIZER: Mutex<()>` with the `#[serial_test::serial]` attribute applied at the module level, which is the established pattern already used by other crates in this repo. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4213dd2 to
1b08e39
Compare
Depends #1640 # What does this PR do? This PR is a follow up of #1585 and #1640 which implement OTel process context publication. It adds a proper handling of the case of publishing a new context after a `fork`. # Motivation Some language runtimes (e.g. Python or Ruby) resorts to `fork`. In this case, the OTel process context of the child must be re-published (the process context of the parent is explicitly NOT inherited through `MADVISE_DONTFORK`). However, since they share the same copy of the static handler, prior to this PR, the publication would try to access the non-inherited mapping, potentially causing a crash. This PR properly handles this case by storing the PID of the publisher, so that upon update, we can detect if there's been a fork since (and we are a child), in which case we can re-create a mapping from scratch. # How to test the change? There is currently no test, because having tests that `fork` is not trivial to set up in the current Rust test framework (it is admittedly possible, but is a larger question that should be treated separately IMHO). However, two follow-up PRs are coming with an FFI and libdatadog-side protobuf encoding of the payload, which will make it possible to test the fork behavior e.g. from Ruby, once they land. Co-authored-by: yann.hamdaoui <yann.hamdaoui@datadoghq.com>
Depends #1650 # What does this PR do? Follow-up of #1585 #1640 #1650 Adds the protobuf definition for the OTel process context and associated messages, and make the interface of the publisher higher-level by taking the new structured `ProcessContext` value instead of a raw bytes payload. # Motivation Since libdatadog is already taking care of some protobuf encoding, and it's supposedly faster and simpler to do here rather than on the side of each language runtime, it makes sense to offer an interface with a struct that is encoded by libdatadog. The process context will be a `ProcessContext`-based opaque pointer on the FFI side, with proper setters/getters. # Additional Notes I was not sure where to put the protobuf definition, as there are a bunch of protobuf-dedicated crates in libdatadog. I feel like the OTel process context is about tracing metadata, but I'm happy to move it elsewhere if it makes more sense. # How to test the change? Once the FFI lands, we'll be able to publish the context from a language runtime and check the whole process end-to-end. For now, I feel like an additional test would mostly test `prost`, which isn't very valuable. Co-authored-by: yann.hamdaoui <yann.hamdaoui@datadoghq.com>
# What does this PR do? [feat: process context publication](#1585) [ci: pass macos label to downstream project](#1647) [chore: implement otel process ctx update](#1640) [chore(crashtracking): emit a best effort stacktrace for Mac](#1645) [ci: remove depth so it can cause problems when getting the diffs](#1657) [build(macOS): set the LC_ID_DYLIB for mac binaries to set correct name for linking](#1646) [chore(ci): fix crashtracker receiver binary rpath setting](#1652) [chore(deps): bump blazesym to 0.2.3 and blazesym-c to 0.1.7](#1654) [feat: otel process ctxt protobuf encoding](#1651) [chore(crashtracker): fix benchmark job](#1664) # Motivation What inspired you to submit this pull request? # Additional Notes Anything else we should know when reviewing? # How to test the change? Describe here in detail how the change can be validated. Co-authored-by: gyuheon.oh <gyuheon.oh@datadoghq.com>
What does this PR do?
This PR implements the missing update sequence of the OTel process context. This allows for modification of an already published OTel process context.
Motivation
This PR is a planned follow-up of #1585, which was knowingly incomplete: it could publish a fresh context, but wouldn't be able to update the context. This PR implements the missing update functionality. See the OTEP spec mentioned above for more information about the general motivation.
Additional Notes
This only part of #1585 follow-ups. In particular, it does not handle forks (where we should publish a new context instead of updating it if there's been a fork since last publication), which is left for a follow-up.
How to test the change?
This PR includes a test for the update sequence. It could also be hooked up in workflow where any reader implementation of the OTEP spec could try to read a published/updated context.