fix(llmobs): honor Feature Flags configuration source for prompts

[PROFeNoM]

Description

Problem

PromptManager._fetch_from_ff() uses the now-deprecated DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED value as a separate activation gate and then enables Remote Configuration unconditionally.

That became incorrect when #19331 introduced agentless, remote_config, and disabled as the authoritative resolved sources, defaulting to agentless. PromptManager was never updated to follow that resolved decision. Consequently, stable agentless and remote_config configurations can silently use /resolve. Prompt retrieval still works, but the local Feature Flag exposure needed for experiment attribution is lost.

The required lifecycle is:

Resolved source	Required action
disabled	Neither helper; fall back to /resolve
agentless	_ensure_ffe_provider() only
remote_config	_ensure_ffe_rc() and _ensure_ffe_provider()

Just as a quick reminder:

• _ensure_ffe_provider() is essential as PromptManager evaluates against the private datadog-llmobs-prompts OpenFeature domain; Without it, the SDK uses its no-op provider or potentially an unrelated application provider.
• _ensure_ffe_rc() is necessary only for remote_config, as removing would effectively make local RC prompt evaluation supported only under ddtrace-run, an unintended compatibility break.

What changes

Prompt-backed Feature Flags now honor the existing resolved Feature Flagging configuration source.

• disabled retains the existing HTTP /resolve fallback.
• remote_config lazily enables the existing Remote Configuration path.
• agentless and remote_config register and use the existing DataDogProvider for local evaluation.

Testing

Added a regression test

Risks

Low. The change only replaces the obsolete Prompt Manager activation gate with the already-resolved Feature Flagging source and preserves the HTTP fallback.

Additional Notes

I also had to add move resolver/constants to openfeature.py since the detect_layering_violation would otherwise fail as I'm using them in LLMObs's code and i couldn't find a way to elegantly work around that without adding code there. It's simply moving code around.

[datadog-datadog-prod-us1]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

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

[cit-pr-commenter-54b7da]

Dependency direction analysis

⚠️ Existing dependency direction violations

There are 250 dependency direction violations that already exist on the base branch and have not been changed by this PR.

Show existing violations (showing 5 of 250 highest severity)

ddtrace.internal.tracemethods -×-> ddtrace.trace  (internal-core -> product:tracing, score=135)
ddtrace.llmobs._integrations.base -×-> ddtrace.trace  (product:llmobs -> product:tracing, score=133)
ddtrace.debugging._debugger -×-> ddtrace.trace  (product:debugging -> product:tracing, score=133)
ddtrace.debugging._exception.replay -×-> ddtrace.trace  (product:debugging -> product:tracing, score=133)
ddtrace.llmobs._integrations.vllm -×-> ddtrace.trace  (product:llmobs -> product:tracing, score=133)

To see all violations, download the layers-base.json and layers-pr.json artifacts from this CI job and run:

uv run --script scripts/import-analysis/layers.py compare layers-base.json layers-pr.json

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-21 11:05:22

Comparing candidate commit b8f2c9f in PR branch codex/fix-prompt-configuration-source with baseline commit 1ebd331 in branch main.

📊 Benchmarking dashboard

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

scenario:httppropagationextract-empty_headers

• 🟥 execution_time [+127.525ns; +157.966ns] or [+12.351%; +15.300%]

scenario:httppropagationinject-ids_only

• 🟥 execution_time [+1.591µs; +1.756µs] or [+8.210%; +9.063%]

scenario:iastaspects-casefold_noaspect

• 🟥 execution_time [+40.623µs; +50.358µs] or [+16.309%; +20.218%]

scenario:iastaspects-swapcase_aspect

• 🟥 execution_time [+42.086µs; +53.218µs] or [+14.978%; +18.940%]

scenario:iastaspectsospath-ospathbasename_aspect

• 🟥 execution_time [+110.719µs; +118.853µs] or [+26.682%; +28.642%]

scenario:iastaspectssplit-rsplit_aspect

• 🟥 execution_time [+17.214µs; +21.776µs] or [+11.849%; +14.990%]

scenario:span-start

• 🟥 execution_time [+1.351ms; +1.524ms] or [+8.954%; +10.097%]

scenario:telemetryaddmetric-1-count-metric-1-times

• 🟥 execution_time [+389.578ns; +426.058ns] or [+14.743%; +16.124%]

scenario:tracer-small

• 🟥 execution_time [+28.064µs; +30.824µs] or [+8.341%; +9.161%]

Unstable benchmarks

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

scenario:coreapiscenario-context_with_data_listeners

• unstable execution_time [-793.417ns; +691.545ns] or [-7.237%; +6.308%]

scenario:coreapiscenario-core_dispatch_1_listener

• unstable execution_time [-30.926ns; +35.484ns] or [-5.066%; +5.813%]

scenario:coreapiscenario-core_dispatch_50_listeners

• unstable execution_time [-1610.982ns; +1681.425ns] or [-9.516%; +9.932%]

scenario:coreapiscenario-core_dispatch_exception_listeners

• unstable execution_time [-1251.343ns; +1307.930ns] or [-9.380%; +9.804%]

scenario:coreapiscenario-core_dispatch_listeners

• unstable execution_time [-320.492ns; +330.164ns] or [-8.761%; +9.026%]

scenario:coreapiscenario-core_dispatch_no_args_listeners

• unstable execution_time [-247.562ns; +253.763ns] or [-8.569%; +8.784%]

scenario:coreapiscenario-core_dispatch_with_results_1_listener

• unstable execution_time [-75.662ns; +69.054ns] or [-6.672%; +6.089%]

scenario:coreapiscenario-core_dispatch_with_results_50_listeners

• unstable execution_time [-3952.165ns; +4007.984ns] or [-9.763%; +9.901%]

scenario:coreapiscenario-core_dispatch_with_results_listeners

• unstable execution_time [-794.124ns; +776.337ns] or [-9.631%; +9.415%]

scenario:packagesupdateimporteddependencies-import_many_stdlib_cached

• unstable execution_time [-61424.167ns; +60020.297ns] or [-9.575%; +9.356%]

[cit-pr-commenter-54b7da]

Circular import analysis

⚠️ Existing circular imports

There are 3 circular imports that already exist on the base branch and have not been changed by this PR.

ddtrace.errortracking._handled_exceptions.bytecode_injector -> ddtrace.errortracking._handled_exceptions.callbacks -> ddtrace.errortracking._handled_exceptions.collector -> ddtrace.errortracking._handled_exceptions.bytecode_reporting -> ddtrace.errortracking._handled_exceptions.bytecode_injector
ddtrace.llmobs -> ddtrace.llmobs._evaluators -> ddtrace.llmobs._evaluators.format -> ddtrace.llmobs._experiment -> ddtrace.llmobs
ddtrace.appsec._asm_request_context -> ddtrace.appsec._iast._iast_request_context_base -> ddtrace.appsec._iast._iast_env -> ddtrace.appsec._iast.reporter -> ddtrace.appsec._exploit_prevention.stack_traces -> ddtrace.appsec._asm_request_context

[cit-pr-commenter-54b7da]

Codeowners resolved as

Resolved from the full PR diff against main using the target branch CODEOWNERS file.
CODEOWNERS team requests not listed below are not required by the current file set.

No remaining files require a CODEOWNERS review.

[PROFeNoM]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: d7bfc39e24

ℹ️ 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".

[KowalskiThomas]

Please accept the suggestion if it makes sense. Otherwise LGTM.

[PROFeNoM]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-21 13:59:13 UTC ℹ️ Start processing command /merge

---

2026-08-21 13:59:22 UTC ℹ️ MergeQueue: Pull request is not mergeable yet

It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.

• Run /code blockers to see what is blocking it.
• Run /remove to cancel it.

---

2026-08-21 14:48:28 UTC ⚠️ MergeQueue: This merge request was unqueued

alexandre.choura@datadoghq.com unqueued this merge request

[PROFeNoM]

/code blockers

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-21 14:45:40 UTC ℹ️ Start processing command /code blockers

---

2026-08-21 14:45:40 UTC ℹ️ Devflow:

Checking merge blockers for #19809...

---

2026-08-21 14:45:50 UTC ℹ️ Devflow: /code blockers

No merge blockers detected.

[PROFeNoM]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-21 14:48:51 UTC ℹ️ Start processing command /merge

---

2026-08-21 14:48:56 UTC ℹ️ MergeQueue: pull request added to the queue

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

---

2026-08-21 15:30:05 UTC ℹ️ MergeQueue: This merge request was merged