Telemetry: send events in forked children

[p-datadog]

What does this PR do?
Changes telemetry to send events in forked children

Motivation:
Dynamic Instrumentation / Live Debugger require telemetry app-heartbeat events to properly render UI. These events are normally sent from forked children in forking web servers, and presently are missing for most customers.

Change log entry
Yes: fix Live Debugger / Dynamic Instrumentation UI for forking web servers

Additional Notes:
Telemetry has some special logic to deal with app-started/configuration-change events due to the component tree being created multiple times by dd-trace-rb, but system tests expecting a single set of events.

This PR further augments that logic to go back from configuration-change events to app-started in the forked children, which are reported as brand new processes.

How to test the change?

Tests added

[github-actions]

Thank you for updating Change log entry section 👏

^{Visited at: 2025-11-20 18:37:32 UTC}

[github-actions]

Typing analysis

Note: Ignored files are excluded from the next sections.

steep:ignore comments

This PR introduces 1 steep:ignore comment.

steep:ignore comments (+1-0)

❌ Introduced:

lib/datadog/core/telemetry/worker.rb:281

Untyped methods

This PR introduces 5 partially typed methods, and clears 1 untyped method and 5 partially typed methods. It increases the percentage of typed methods from 54.48% to 54.68% (+0.2%).

Untyped methods (+0-1)

✅ Cleared:

sig/datadog/core/utils/only_once.rbs:16
└── def reset_ran_once_state_for_tests: () -> untyped

Partially typed methods (+5-5)

❌ Introduced:

sig/datadog/core/telemetry/event/app_started.rbs:19
└── def configuration: (untyped settings, Core::Configuration::AgentSettings agent_settings) -> Array[Hash[Symbol, untyped]]
sig/datadog/core/telemetry/event/app_started.rbs:23
└── def conf_value: (String name, untyped value, Integer seq_id, String origin) -> Hash[Symbol, untyped]
sig/datadog/core/telemetry/event/app_started.rbs:27
└── def install_signature: (untyped settings) -> Hash[Symbol, Object]
sig/datadog/core/telemetry/event/app_started.rbs:29
└── def get_telemetry_origin: (untyped settings, String config_path) -> String
sig/datadog/core/telemetry/event/synth_app_client_configuration_change.rbs:8
└── def payload: () -> { ?products: untyped, configuration: untyped, ?install_signature: untyped }

✅ Cleared:

sig/datadog/core/telemetry/event/app_started.rbs:17
└── def configuration: (untyped settings, Core::Configuration::AgentSettings agent_settings) -> Array[Hash[Symbol, untyped]]
sig/datadog/core/telemetry/event/app_started.rbs:21
└── def conf_value: (String name, untyped value, Integer seq_id, String origin) -> Hash[Symbol, untyped]
sig/datadog/core/telemetry/event/app_started.rbs:25
└── def install_signature: (untyped settings) -> Hash[Symbol, Object]
sig/datadog/core/telemetry/event/app_started.rbs:27
└── def get_telemetry_origin: (untyped settings, String config_path) -> String
sig/datadog/core/telemetry/event/synth_app_client_configuration_change.rbs:8
└── def payload: () -> { configuration: untyped }

If you believe a method or an attribute is rightfully untyped or partially typed, you can add # untyped:accept to the end of the line to remove it from the stats.

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 82.76%
• Total Coverage: 98.49% (-0.05%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: f2e7239 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-11-20 19:18:46

Comparing candidate commit f2e7239 in PR branch telemetry-in-children with baseline commit 651c3ba in branch master.

Found 1 performance improvements and 1 performance regressions! Performance is the same for 42 metrics, 2 unstable metrics.

scenario:profiling - sample+serialize retain_every=10 heap_samples=false heap_size=false heap_sample_every=1 skip_end_gc=false

• 🟥 throughput [-0.182op/s; -0.163op/s] or [-6.544%; -5.870%]

scenario:tracing - Propagation - Trace Context

• 🟩 throughput [+4010.282op/s; +4124.143op/s] or [+11.833%; +12.169%]

[ivoanjo]

I don't think this is the right way to go -- I think this is bending the OnlyOnce in a really weird direction generally only to support a specific use-case of one of its users.

Rather than resetting the only once, consider creating a new instance?