feat(openfeature): add agentless configuration and source resolution

[pavlokhrebto]

What does this PR do?

Adds the stable Feature Flags configuration surface, source resolution, and validated agentless endpoint derivation. It includes the configuration registry entries, RBS signatures, documentation, and focused unit coverage.

Motivation:

This is PR 1 of a four-PR stack that splits agentless Feature Flags delivery into focused changes for easier review. This PR intentionally contains dead code and must not be merged without its child PRs; the complete stack will be merged atomically.

Change log entry

Yes. Adds configuration options for agentless Feature Flags delivery.

Additional Notes:

Important

WE WILL NOT MERGE THIS PR WITHOUT ITS CHILD PRS.
The configuration and source-resolution code introduced here has no production caller until the child PRs are applied.

PR 1 targets master, and each subsequent PR targets the preceding PR's branch. We will merge PR 4 → PR 3 → PR 2 → PR 1 → master, so only the complete stack reaches master.

How to test the change?

Run bundle exec rake local_config_map:generate, targeted StandardRB and Steep checks for lib/datadog/open_feature/configuration and spec/datadog/open_feature/configuration, then bundle exec rake compile && bundle exec rake test:open_feature on Ruby 3.1 and Ruby 4.0.

[linear-code]

FFLSDK-10

[dd-octo-sts]

Thank you for updating Change log entry section 👏

^{Visited at: 2026-09-08 10:36:52 UTC}

[datadog-prod-us1-5]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 98.93%
• Overall Coverage: 90.43% (+0.07%)

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

[Copilot]

🟡 Changes recommended

The new RBS signatures don’t currently match Ruby method visibility (private class methods) and need small convention/formatting adjustments to align with existing sig patterns.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Introduces the stable OpenFeature Feature Flags configuration surface for agentless delivery, including source selection/resolution and validated derivation of the agentless configuration endpoint, plus the associated registry, RBS, docs, and unit specs.

Changes:

• Add stable Feature Flags settings (enablement, configuration source, agentless endpoint controls) with validation and legacy-switch deprecation logging.
• Implement configuration-source resolution (agentless/remote_config/offline) and validated agentless endpoint building.
• Register new environment variables in the supported-configurations registry and document the new configuration surface.

File summaries

File	Description
supported-configurations.json	Registers new Feature Flags/OpenFeature-related environment variables and defaults.
lib/datadog/core/configuration/supported_configurations.rb	Adds the new env var names to the supported configuration allowlist.
lib/datadog/open_feature/configuration.rb	Defines stable OpenFeature Feature Flags settings, validation, and legacy deprecation warning behavior.
lib/datadog/open_feature/configuration/source.rb	Adds source-selection resolution logic and fail-closed handling for invalid sources.
lib/datadog/open_feature/configuration/source/resolution.rb	Adds a small value object to carry resolved source + enablement.
lib/datadog/open_feature/configuration/agentless_endpoint.rb	Implements validated construction of managed/custom agentless delivery endpoints.
docs/GettingStarted.md	Documents the new Feature Flags configuration knobs and deprecation notes.
spec/datadog/open_feature/configuration/settings_spec.rb	Adds unit coverage for new OpenFeature settings parsing, validation, and precedence.
spec/datadog/open_feature/configuration/source_spec.rb	Adds unit coverage for source resolution precedence and invalid-value behavior.
spec/datadog/open_feature/configuration/source/resolution_spec.rb	Adds basic unit coverage for the Resolution value object.
spec/datadog/open_feature/configuration/agentless_endpoint_spec.rb	Adds unit coverage for managed/custom endpoint derivation and validation.
sig/datadog/open_feature/configuration.rbs	Extends signatures to include new settings constants and helper method.
sig/datadog/open_feature/configuration/source.rbs	Adds signatures for source resolution and its settings interface.
sig/datadog/open_feature/configuration/source/resolution.rbs	Adds signatures for the Resolution value object.
sig/datadog/open_feature/configuration/agentless_endpoint.rbs	Adds signatures for AgentlessEndpoint construction/shape.
sig/datadog/core/configuration/settings.rbs	Extends the OpenFeature settings interface with the new settings accessors.

Review details

• Files reviewed: 16/16 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 38037229a2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[TonyCTHsu]

Design/naming feedback on the configuration surface. Flagging now while changes are still cheap.

[TonyCTHsu]

Approve. Naming/layout feedback all addressed; the polymorphism thread is closed with a follow-up tracked in the replies. One non-blocking note inline on the initialization timeout env var.

[TonyCTHsu]

Now that the settings namespace moved to c.feature_flags.*, lib/datadog/open_feature/ is the remaining vocabulary mismatch in the subsystem — the module says OpenFeature while the settings say feature_flags. (6292's stale settings.open_feature.initialization_timeout_ms references are a direct symptom: two vocabularies coexisting in one stack invites exactly that class of rebase bug.)

Question: is the module name dictated by cross-SDK convention, or is a rename on the table? If it's open for discussion, the target I'd propose is the flat

Datadog::FeatureFlags::OpenFeatureProvider

matching the Vendor::OpenFeatureProvider convention the broader OpenFeature ecosystem uses (JS LaunchDarklyProvider, Java com.launchdarkly.openfeature.LaunchDarklyProvider), which also finally pairs the code namespace with the feature_flags settings root. To be explicit about scope: the proposal is moving the whole module to Datadog::FeatureFlags ("lib/datadog/feature_flags/" — Component, Remote, Activation, evaluators, and the rest), with the provider flattened to the constant above. Every Datadog::OpenFeature::* constant other than the provider is internal and moves freely; only the two shimmed names below are public API.

Compatibility cost is two shims: alias Datadog::OpenFeature::Provider (shipped API since Oct 2025, referenced in customer initializers) and keep datadog/open_feature/provider.rb as a require-path shim.

If the stack-before-merge moment is the only cheap window for the new code, it's now; if the name is fixed by the cross-SDK spec, happy to close this and keep Datadog::OpenFeature::Provider.

[pavlokhrebto]

On the Datadog::OpenFeature namespace: I would like to keep it as-is. feature_flags names the Datadog product configuration, while OpenFeature names the integration/API boundary exposed by this provider. That separation is also consistent with the other SDKs: Go uses the openfeature package, Java uses datadog.trace.api.openfeature, Python uses internal/openfeature, and .NET uses Datadog.FeatureFlags.OpenFeature. The existing Ruby constant and require path have also shipped and are documented, so renaming them would add permanent compatibility aliases and require-path shims without changing behavior.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-09-23 10:10:29

Comparing candidate commit ec3aa99 in PR branch pavlo.khrebto/FFLSDK-10/agentless-configuration with baseline commit b664c8c in branch master.

📊 Benchmarking dashboard

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