Request feature flag config on the first RC poll

[leoromanovsky]

Motivation

A customer can hit this even when the Datadog Agent has already been running for hours. The important moment is when the Java tracer starts.

When a new tracer RC client first talks to the Agent, the Agent has a fast path to fetch config for that new client. If Java's first RC request does not ask for FFE_FLAGS, the Agent cannot fetch feature flag config on that fast path. Java may ask for FFE_FLAGS on a later poll, but by then the Agent already knows that RC client, so the later request can wait for the normal Agent refresh path. That is the startup window where the OpenFeature provider can stay on default values even though the application is already running.

This PR makes Java ask for feature flag config on the first RC request from the tracer. That lets an already-running Agent fetch FFE_FLAGS immediately for the newly-started tracer, instead of discovering the product after the new-client fast path was missed.

Changes

Start the feature flagging subsystem before the shared remote-config poller is started from Agent startup. Feature flagging already registers the FFE_FLAGS listener and capability with the shared poller; moving it before maybeStartRemoteConfig ensures those fields are present when the immediate first poll is scheduled.

The OpenFeature smoke test now asserts the first captured /v0.7/config request already includes FFE_FLAGS and CAPABILITY_FFE_FLAG_CONFIGURATION_RULES. The test comment calls out why this is the important behavior: for an Agent that is already running, the first request from this newly-started tracer is the request that can use the Agent's new-client cache bypass.

Decisions

This mirrors the Go tracer early FFE RC subscription pattern without changing provider evaluation semantics, initialization timeout behavior, or the Agent remote-config service. In Go, startRemoteConfig calls internalffe.SubscribeRC() before starting the RC client when the flagging provider is enabled: https://github.com/DataDog/dd-trace-go/blob/080ee3ab146e57344317a5ac48b2686735bf10fb/ddtrace/tracer/remote_config.go#L510-L512. The OpenFeature subscription helper documents the same first-poll requirement: https://github.com/DataDog/dd-trace-go/blob/080ee3ab146e57344317a5ac48b2686735bf10fb/internal/openfeature/rc_subscription.go#L42-L45.

The smoke test is intentionally tracer-side because it checks the invariant dd-trace-java owns: the tracer must advertise FFE on its first RC request. A full Nasdaq reproduction still belongs in system-tests or Agent coverage: Agent already running with no FFE_FLAGS cache, backend able to return FFE only after the new tracer advertises that product, and the first tracer response validated for fast delivery.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Startup Time

Scenario	This PR	master	Change
insecure-bank / iast	13,985 ms	13,979 ms	+0.0%
insecure-bank / tracing	12,866 ms	12,976 ms	-0.8%
petclinic / appsec	16,613 ms	16,498 ms	+0.7%
petclinic / iast	16,512 ms	16,528 ms	-0.1%
petclinic / profiling	16,359 ms	16,574 ms	-1.3%
petclinic / tracing	15,900 ms	14,934 ms	+6.5%

Commit: 1a4f70a4 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-27 03:15:33 UTC ℹ️ Start processing command /merge

---

2026-05-27 03:15:37 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-05-27 04:28:02 UTC ℹ️ MergeQueue: This merge request was merged