fix(llmobs): submit eval metrics through the shared HTTP clients

[ddog-thibault-nadin]

What Does This Do

Makes EvalProcessingWorker post through the HTTP clients held by SharedCommunicationObjects instead of a raw new OkHttpClient():

• non-agentless → sco.agentHttpClient
• agentless → sco.getIntakeHttpClient()

Motivation

When the Agent is reached over a Unix domain socket or a named pipe, SharedCommunicationObjects.parseAgentUrl only stores a placeholder URL:

if (agentUrl.startsWith("unix:")) {
  // provide placeholder agent URL, in practice we'll be tunnelling over UDS
  agentUrl = "http://" + config.getAgentHost() + ":" + config.getAgentPort();
}

The real transport is the socket factory configured on agentHttpClient. The worker built its own client, so it posted to that placeholder host:port where nothing listens: SubmitEvaluation silently reaches nobody in those supported setups.

The agentless branch is not broken in the same way, but its own client ignored getAgentTimeout() and forceClearTextHttpForIntakeClient. getIntakeHttpClient() honours both and is built without UDS/named pipe, which is what a direct intake call needs.

LLMObsSystem.start already calls sco.createRemaining(config) before constructing the worker, so both clients are initialised by then.

[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

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.97 s	13.99 s	[-0.8%; +0.4%] (no difference)
startup:insecure-bank:tracing:Agent	12.93 s	12.96 s	[-1.1%; +0.6%] (no difference)
startup:petclinic:appsec:Agent	16.88 s	16.52 s	[+1.3%; +3.1%] (significantly worse)
startup:petclinic:iast:Agent	16.86 s	16.96 s	[-1.4%; +0.2%] (no difference)
startup:petclinic:profiling:Agent	16.75 s	16.76 s	[-1.1%; +1.1%] (no difference)
startup:petclinic:sca:Agent	16.69 s	16.32 s	[+1.5%; +3.0%] (significantly worse)
startup:petclinic:tracing:Agent	15.63 s	16.37 s	[-8.7%; -0.4%] (maybe better)

Commit: 8dc93b39 · 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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: aef47d25b2

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

[chatgpt-codex-connector]

Keep HTTPS eval submissions off the cleartext intake client

When DD_FORCE_CLEAR_TEXT_HTTP_FOR_INTAKE_CLIENT is enabled, getIntakeHttpClient() builds the shared intake client as cleartext-only via OkHttpUtils.buildHttpClient, but the agentless eval URL above is still hard-coded to https://api.<site>/.... OkHttp rejects HTTPS requests on a ConnectionSpec.CLEARTEXT-only client, so enabling that supported intake flag for another backend intake now disables LLMObs agentless eval submissions; use an HTTPS-capable client for HTTPS eval URLs or honor the configured LLMObs agentless URL before sharing this client.

Useful? React with 👍 / 👎.

[aniszoubiramar]

@ddog-thibault-nadin could you look to this comment please

[datadog-prod-us1-4]

More details

The worker now receives the already-configured shared client in both agent and agentless modes, preserving UDS/named-pipe routing and intake timeout/clear-text settings. Focused compilation and the shared communication tests found no reproducible behavioral regression; no additional tests recommended because the available production lifecycle initializes the shared clients before the worker.

Was this helpful? React 👍 or 👎

_{📊 Validated against 2 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit aef47d2 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[datadog-prod-us1-4]

The new agentless URL validation accepts ftp:// and file://, but the worker passes them to OkHttp’s HTTP(S)-only parser during startup. A malformed URL configuration can therefore disable LLM Observability instead of falling back to the default intake.

_{📊 Validated against 11 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit 8dc93b3 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[datadog-prod-us1-4]

Reject URL schemes unsupported by OkHttp

A syntactically valid but unsupported configured scheme prevents LLM Observability initialization instead of safely using the default intake.

Assertion details

• Input: Enable agentless LLMObs and set DD_LLMOBS_AGENTLESS_URL to ftp://localhost:9126 or file:///tmp/llmobs.
• Expected: The shared URL validator should accept only HTTP and HTTPS schemes, causing unsupported schemes to fall back to the default intake. Because sibling CI Visibility call sites use the same helper, a line-local suggestion here would be incomplete.
• Actual: The new initialization uses generic isValidUrl, which accepts ftp:// and file://. Both temporary cases retained the value, although EvalProcessingWorker subsequently passes it to OkHttp's HTTP(S)-only HttpUrl.get. The shared validator is also used by sibling CI Visibility intake URL configuration, so the complete fix belongs in that helper rather than only this assignment.

Was this helpful? React 👍 or 👎
_{🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}