feat(debugger): include runtime_id in snapshot payloads

[watson]

What does this PR do?

Adds the tracer's per-process runtime_id at the root of every snapshot payload, in both agent and agentless mode.

 {
   "ddsource": "dd_debugger",
   "hostname": "...",
   "service": "...",
+  "runtime_id": "3b9c3a4e-...",
   "message": "...",
   "logger": { ... },
   "dd": { "trace_id": "...", "span_id": "..." },
   "debugger": { "snapshot": { ... } }
 }

Opened as a draft: it's meant as a concrete starting point for agreeing, across tracers, on where this field lives.

Motivation

Gap 1 of the RFC: Improving Correlation for Live Debugger Snapshots: two snapshots from the same container, one from before and one from after a restart, can't be told apart from their payloads. Host and container tags are the same, and inside a container the process id in logger.thread_id is often the same after every restart too.

The tracers don't agree on where, or whether, they send it today:

Tracer	In the snapshot payload	As a ddtags tag
Ruby	yes, at the root (since v2.42.0)	yes (runtime-id)
Python	no; open DataDog/dd-trace-py#19466 adds debugger.snapshot.runtime_id	no
Java	no	no
Go	no; DataDog/datadog-agent#56772 defers it	no
.NET	no	yes (runtime-id)
PHP	no	yes (runtime_id, only when env and version are set)
Node (before this PR)	no	agentless only (runtime_id)

The Agent's debugger proxy doesn't add a runtime id either.

Additional Notes

• Why the root: that's where Ruby already emits it, and it's one of the two places the shared test_runtime_id_in_envelope system test looks (root runtime_id or dd.runtime_id). The test only reads the payload, never the ddtags query string. Python's open PR uses a location the test doesn't read.
• Open question for the team: what to do with the existing agentless-only runtime_id tag. This PR leaves it as is. The duplication is harmless, and no explanation was recorded for why the tag is agentless-only.
• Not tied to coordinated sampling: this is independent of the coordinated snapshot sampling PR, feat(debugger): coordinate snapshot sampling per trace #10677 (DEBUG-5831). The system-tests manifest entry for test_runtime_id_in_envelope can be flipped once this ships.

Validation:

• ./node_modules/.bin/mocha packages/dd-trace/test/debugger/devtools_client/send.spec.js: 27 passing. The expected payloads include runtime_id in agent mode, and the agentless test asserts it too.
• ./node_modules/.bin/mocha --timeout 60000 integration-tests/debugger/input-messages.spec.js integration-tests/debugger/probe-file.spec.js integration-tests/debugger/tracing-integration.spec.js: 11 passing. The shared basic-input assertion now checks that runtime_id is a UUID equal to the runtime-id tag of the request span.
• npm run test:debugger: 821 passing.
• Mutation check: removing the field fails 3 unit tests and the integration assertion.
• ESLint on all changed files. tsc -p tsconfig.debugger.json reports no new errors.

🤖 Generated with Claude Code

[dd-octo-sts]

Overall package size

Self size: 9.44 MB
Deduped: 10.19 MB
No deduping: 10.19 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.5.1 | 127.66 kB | 531.94 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[datadog-datadog-prod-us1]

✅ All CI checks and tests passed. Datadog automation helped this PR pass.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🔄 Datadog retried 4 tests - 4 passed on retry

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 98.28% (+0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 344719a | Docs | View more details | Give us feedback!}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.87%. Comparing base (a505931) to head (344719a).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #10678   +/-   ##
=======================================
  Coverage   98.87%   98.87%           
=======================================
  Files        1058     1058           
  Lines      171887   171895    +8     
  Branches       74       74           
=======================================
+ Hits       169949   169957    +8     
  Misses       1938     1938           

Flag	Coverage Δ
ai-guard	63.76% <ø> (-0.02%)	⬇️
apm-capabilities	54.72% <ø> (+<0.01%)	⬆️
apm-integrations	80.98% <ø> (-0.02%)	⬇️
appsec	57.88% <ø> (-0.01%)	⬇️
debugger	69.86% <100.00%> (-0.03%)	⬇️
instrumentation	55.36% <ø> (-0.01%)	⬇️
llmobs	80.70% <ø> (-0.02%)	⬇️
master-coverage	98.87% <100.00%> (?)
openfeature	67.34% <ø> (-0.02%)	⬇️
platform	68.57% <ø> (+<0.01%)	⬆️
profiling	65.98% <ø> (-0.02%)	⬇️
serverless	65.59% <ø> (-0.02%)	⬇️
test-optimization	81.86% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-10-07 19:01:00

Comparing candidate commit 344719a in PR branch watson/snapshot-runtime-id with baseline commit a505931 in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 0 performance regressions! Performance is the same for 2392 metrics, 11 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 ----------------------------------'

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:appsec-iast-no-vulnerability-iast-enabled-default-config-24

• unstable max_rss_usage [-27.957MB; +7.978MB] or [-8.502%; +2.426%]

scenario:debugger-line-probe-without-snapshot-26

• unstable cpu_user_time [-1008.192ms; +2274.215ms] or [-10.590%; +23.888%]
• unstable execution_time [-995.742ms; +2271.370ms] or [-9.348%; +21.324%]
• unstable throughput [-231.087op/s; +102.031op/s] or [-21.403%; +9.450%]

scenario:encoders-0.4-immediate-flush-20

• unstable max_rss_usage [-2.080MB; +6.724MB] or [-2.455%; +7.936%]

scenario:llmobs-span-processor-retrieval-20

• unstable execution_time [-128.827ms; +201.261ms] or [-4.359%; +6.809%]

scenario:log-with-debug-20

• unstable max_rss_usage [-8.343MB; +5.138MB] or [-7.251%; +4.466%]

scenario:openfeature-scale-full-26

• unstable max_rss_usage [-35.229MB; +21.231MB] or [-13.859%; +8.352%]

scenario:openfeature-typical-full-20

• unstable max_rss_usage [-7.891MB; +13.272MB] or [-5.220%; +8.780%]

scenario:plugin-dns-lookup-24

• unstable execution_time [-116.208ms; +183.131ms] or [-4.978%; +7.844%]

scenario:plugin-graphql-long-with-depth-on-max-26

• unstable max_rss_usage [-38.633MB; +24.915MB] or [-15.011%; +9.681%]