This reverts commit 51eec38.

The 'when dynamic instrumentation is fully enabled' context stubs
Datadog::DI::Component.build to a non-nil fake so the enabled-DI
code path runs in CI configurations without the DI C extension.
That stub bypasses Component.build's runtime check, so
Components#startup! reaches Datadog::DI.activate_tracking — which
is loaded only from datadog/di/boot.rb under
RUBY_VERSION >= '2.6' && RUBY_ENGINE != 'jruby' (lib/datadog.rb:19).
On Ruby 2.5 the method is undefined, and the spec fails with
NoMethodError.

'DI fully enabled' is a state that cannot exist on Ruby 2.5 in
production (DI requires MRI 2.6+, per DI.unsupported_reason). Skip
the context on Ruby <2.6, matching the existing pattern in
spec/datadog/core/configuration/components_spec.rb:797.

This is the test-side fix for the failure that 51eec38 patched
in production. The production-side workaround was reverted at
51c1fef because it added respond_to?(:activate_tracking) guards
to lib/datadog/core/configuration/components.rb:245 and
lib/datadog/di/remote.rb:77 — guards that are dead in production
(the outer 'if dynamic_instrumentation' already short-circuits on
every platform where activate_tracking could be undefined) and
exist only to make this fixture work on Ruby 2.5. The fix belongs
in the fixture.

The 'Tracing before DI' registration order in
lib/datadog/core/remote/client/capabilities.rb is load-bearing: on a
combined RC dispatch (LIVE_DEBUGGING + APM_TRACING in one transaction),
the Tracing receiver must run first so handle_rc_enablement starts DI
before the DI receiver processes the probe change. The end-to-end
behavior is covered by the combined-RC-transaction test in
spec/datadog/di/integration/implicit_enablement_spec.rb, but that test
exercises the order indirectly through dispatcher behavior.

Add a direct unit assertion on capabilities.receivers order so a future
refactor that reorders registrations is caught at the registration site
rather than via a multi-step integration failure.

Two comment-density tightenings flagged in PR review (non-blocking):

- lib/datadog/core/remote/client/capabilities.rb: the registration-order
  paragraph went from 10 lines to 7. Keeps the constraint (Tracing
  registers before DI) and the silent-drop consequence; drops the
  step-by-step retelling. The full mechanism is regression-tested by
  spec/datadog/di/integration/implicit_enablement_spec.rb's
  combined-payload case.

- lib/datadog/core/configuration/components.rb #state: the using_default?
  paragraph went from 9 lines to 6. Keeps the unique rationale (why
  using_default? rather than !enabled — the Datadog.configure-mutation
  timing), drops the worked example. The "vs default_precedence?"
  rationale lives at DI::Component#explicitly_enabled?; this site's
  rationale is the orthogonal "vs !enabled" choice.

The outer rescue in handle_rc_enablement catches an exception from the
body (e.g. component.start! raising) and then attempts to report it via
`Datadog.send(:components, allow_initialization: false)&.telemetry&.report`.

If the components lookup itself raises (extremely unlikely in steady
state, but possible during teardown races or during early boot before
Components#initialize completes), the rescue body propagates out of
handle_rc_enablement \u2014 defeating the DI contract that DI never raises
into Tracing::Remote.process_config or further into the RC dispatch.

Wrap the telemetry lookup+report in a defensive begin/rescue that
swallows any secondary exception and logs at debug. Add a regression
test that stubs Datadog.send to succeed once then raise, and asserts
handle_rc_enablement does not propagate.

Verified: bundle exec rspec spec/datadog/di/remote_spec.rb (locally,
syntax check only; full run gated on Ruby 2.6+ MRI with C ext).

Commit ea10a35 added an inner begin/rescue around the telemetry
lookup in handle_rc_enablement's rescue clause, plus a test that
simulated the inner call raising.

Tracing both call sites shows neither can actually raise in this
codebase:

- Datadog.send(:components, allow_initialization: false) with
  allow_initialization: false always returns the (possibly nil/false)
  @components value via the COMPONENTS_READ_LOCK.synchronize block.
  No raise path on this branch.
  (lib/datadog/core/configuration.rb:196)

- telemetry.report(e, description:) does string-building from
  exception.class.name/inspect (safe on every Exception), then
  log!(event) which short-circuits on enabled? && @log_collection_enabled
  and otherwise enqueues to the worker. No raise path under realistic
  conditions; the only theoretical path is a customer Exception
  subclass overriding #backtrace to raise, which does not apply here
  because e originates from DI's own code.
  (lib/datadog/core/telemetry/logging.rb:51-69)

The guard was defending against scenarios that don't exist. Remove
the rescue and the simulation test; the outer rescue at line 82 is
sufficient.

…eason

The project-established pattern for Ruby version checks is the
Datadog::RubyVersion helper:

  lib/datadog/di/base.rb:50 -- RubyVersion.is?('>= 2.6')
  lib/datadog.rb:22         -- Datadog::RubyVersion.is?('>= 2.6')

The newly-added DI.unsupported_reason used a bare `RUBY_VERSION < '2.6'`,
which works but diverges from the helper. RubyVersion captures the
running version once as Gem::Version (handles the 3.2.10 < 3.2.3
string-comparison bug) and is the standard idiom.

Switch to Datadog::RubyVersion.is?('< 2.6').

Test impact: the tests that stub_const('RUBY_VERSION', ...) to
exercise the version branch must also stub
Datadog::RubyVersion::CURRENT_RUBY_VERSION, which is the cached
Gem::Version captured at module load time. Established pattern in
spec/datadog/core/configuration/settings_spec.rb:907-908 etc.

Updated stubs:
  - spec/datadog/di_spec.rb: 'all preconditions met',
    'Ruby older than 2.6', 'C extension is not loaded' contexts
  - spec/datadog/di/component_spec.rb: 'Ruby 2.6+ required, mocked'
    context

The error message still interpolates RUBY_VERSION (not CURRENT_RUBY_VERSION),
so both stubs are needed: one for the gate, one for the message.

The four 'returns nil and logs at debug only' tests in component_spec
asserted `expect(logger).to receive(:debug)` without a .with matcher.
That passes for any debug call, including an empty one \u2014 the test
verifies that debug was called and warn was not, but not that the
specific build-precondition reason landed in the log.

The companion 'with DD_DYNAMIC_INSTRUMENTATION_ENABLED explicitly true'
tests in each context already match the warn message content. The
debug counterparts should match the same content, since production
code emits the same string at either level
(logger.public_send(level, 'di: dynamic instrumentation is disabled: <reason>')).

Tighten each debug assertion with a .with(a_string_matching(...))
matcher that pins the specific reason:

  - 'Remote Configuration is not enabled' (RC disabled)
  - 'MRI is required' (non-MRI engine)
  - 'Ruby 2.6+ is required' (Ruby <2.6)
  - 'C extension is not available' (C ext absent)

Also rename each test to name the specific reason instead of the
generic 'logs at debug only'.

The context 'when DI component is started via RC (settings.enabled
false)' did not actually drive RC \u2014 it stubbed started?: true and
left settings.dynamic_instrumentation.enabled at default. The
combination (started + using_default? on :enabled) is exactly what
production code reads to compute di_implicitly_enabled, so the
assertion was correct, but the 'via RC' phrasing overstated the
scope: a unit test against #state cannot, by construction, drive
through Remote.handle_rc_enablement.

Rename both sibling contexts to describe the property under test
(env-var explicit set vs customer never touched the env var) rather
than the upstream driver. Add explanatory comments tying each context
to the production path it models.

No test logic changed.

The component_spec covered the sequential lifecycle (start!/stop!,
idempotence, restart) but not the @lifecycle_mutex's role in
serializing concurrent calls. The mutex comment in component.rb
claimed serialization across start!/stop!/shutdown! \u2014 the claim
was not test-protected.

The behavioral guarantee (two threads calling lifecycle methods
concurrently are serialized) is Ruby's Mutex#synchronize contract,
which we do not re-test here. The mechanism guarantee (each lifecycle
method actually wraps its body in @lifecycle_mutex.synchronize) is
what this PR claims and what these tests verify. A future refactor
that drops the synchronize call from one of the three methods would
be caught at this layer; Ruby's mutex then handles the rest.

Three mechanism tests added, one per lifecycle method:
  - start! acquires @lifecycle_mutex
  - stop! acquires @lifecycle_mutex
  - shutdown! acquires @lifecycle_mutex

Lifecycle method bodies are stubbed so the assertion targets the
mutex acquisition alone; the worker/probe-manager side effects are
already covered by the #start! and #stop! describe above.

process_config runs on the remote-config worker thread. The
telemetry-reporting call at the end used Datadog.send(:components)
with the default allow_initialization: true, which would
synchronously build the entire component tree from the RC worker
thread if @components were nil at dispatch time \u2014 lock acquisition
from the wrong thread, plus the cost of a full tree build on a hot
path.

The realistic exposure is small (the RC client thread is itself part
of the components tree, so dispatch generally cannot precede
initialization), but the asymmetry is real: PR 5525 added
DI::Remote.handle_rc_enablement on the same dispatch path and used
allow_initialization: false correctly. Bring the existing telemetry
call into line.

Switch to:
  Datadog.send(:components, allow_initialization: false)
    &.telemetry&.client_configuration_change!(env_vars)

The &. chain matches the pattern in DI::Remote.handle_rc_enablement.
When components is nil the call is a no-op, which is the right
behavior \u2014 no point reporting a configuration change to a telemetry
component that doesn't exist yet.

Empty line left behind by commit b0fcdb8 when the defensive
rescue test was removed. CI flagged:

  spec/datadog/di/remote_spec.rb:146:1: Layout/EmptyLinesAroundBlockBody:
  Extra empty line detected at block body end.

Trailing blank line removed.

…action under test

The three @lifecycle_mutex serialization tests added in f28d5a8 assert
exactly one synchronize call per lifecycle method:

  expect(mutex).to receive(:synchronize).and_call_original
  component.start!  (or .stop!, .shutdown!)

The after block ran component&.shutdown! for cleanup, which itself calls
@lifecycle_mutex.synchronize. RSpec mock verification runs after the
example's after hooks, so the cleanup's synchronize call was counted
against the expectation — yielding "expected 1 time, received 2 times"
on every Ruby version's batch [0].

Production code (start!, stop!, shutdown!) each calls synchronize
exactly once, as the tests intended to verify. The bug is in the test
fixture, not the production code.

Replace shutdown!-based cleanup with DI.remove_current_component, which
acquires DI::LOCK (a different Mutex on the DI module per
lib/datadog/di/base.rb:21) and does not touch @lifecycle_mutex. The
before block stubs all worker/probe-manager side effects, so no thread
or hook needs stopping — the only state that escapes the example is
the entry that Component.build adds to DI.current_components via
add_current_component.

The expectation remains strict (default "exactly once"); only the
teardown mechanism changes.

Co-Authored-By: Claude <[email protected]>

Addresses review comment from @mabdinur: a LIVE_DEBUGGING probe that
lands in an RC poll while DI is stopped, with the
dynamic_instrumentation_enabled=true signal arriving in a separate later
poll, was dropped and never installed until the customer edited the probe.

Root cause: DI::Remote.receivers ignores LIVE_DEBUGGING changes while the
component is stopped, so the probe never enters the probe repository. When
a later poll flips enablement, Core::Remote::Client#apply_config marks the
unchanged probe content `same` and does not re-dispatch it, and
component.start! -> probe_manager.reopen only replays what is already in
the repository. The existing fixes did not cover this: the Tracing-before-DI
receiver ordering handles the same-poll combined transaction, and the
stop!/reopen repository preservation handles toggling DI off then on after
the probe was already installed.

Fix: on the stopped->started transition, handle_rc_enablement reconciles
against the current LIVE_DEBUGGING contents in the RC repository (threaded
through from Tracing::Remote.process_config) and installs any probe not
already tracked. The DI receiver's :insert path now skips a probe the
reconcile already installed in the same dispatch, so the same-poll combined
transaction does not double-add (which would surface a false errored status).

Verified: new integration test in implicit_enablement_spec drives two real
client.sync polls (probe while stopped, then enable) and asserts the probe
installs; it fails without the fix (installed=0) and passes with it. Full
non-contrib DI suite + tracing remote spec green (862 examples). Steep and
StandardRB clean on changed files.

… RC registration

When DI is explicitly disabled, DI::Component.build returns nil and the
DI RC capability/product/receiver block (including bit 38) is not
registered. Bit 38 moves from Tracing::Remote::CAPABILITIES to
DI::Remote.capabilities so it is gated with the rest of the DI block.
The unset (default) case is unchanged: the component is built stopped
and DI is registered so RC can enable it.

handle_rc_enablement's nil-component branch now distinguishes explicit
disable from unsupported-environment reasons.

Reword four spec comments to drop provenance framing ("raised in PR
review", "codex review scenario", "codex P2 review comment") while
keeping the technical scenario each describes. Process narration belongs
in the PR thread, not in source.

The previous comment claimed the DI component exists "whenever the
runtime supports it". That overstates: Component.build also returns nil
on a supported runtime when DI is explicitly disabled
(DD_DYNAMIC_INSTRUMENTATION_ENABLED=false) or when Remote Configuration
is unavailable. Reword to state the actual build preconditions.