[BUG]: LLM Observability should not throw an unhandled exception if the agent is unavailable.

[ianjkaplan]

Tracer Version(s)

5.82

Node.js Version(s)

24.9

Bug Report

When instrumenting with dd-trace 5.82 with LLM Observability enabled, the library can throw an unhandled exception if connectivity to the Datadog agent is lost (or intermittently unavailable). If the exception is not caught by a top-level uncaughtException handler, it crashes the entire Node.js process.

This behavior does not feel appropriate for non-critical telemetry functionality.

Expected behavior
If the agent is unavailable, dd-trace should gracefully degrade by temporarily disabling LLM Observability until the agent becomes available again.

Actual behavior
The process can crash due to an unhandled exception originating from the LLM Observability path when the agent is unreachable.

Additional notes
If this is a desired improvement, I’m happy to submit a PR implementing this change.

Reproduction Code

n/a The agent was temporarily unavailable. See error stack trace below.

Error Logs

/app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/dd-trace/src/llmobs/index.js:71
      throw new Error(
      ^

Error: Cannot send LLM Observability data without a running agent or without both a Datadog API key and site.
Ensure these configurations are set before running your application.
    at /app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/dd-trace/src/llmobs/index.js:71:13
    at /app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/dd-trace/src/llmobs/writers/util.js:25:7
    at /app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/dd-trace/src/exporters/common/agent-info-exporter.js:15:14
    at ClientRequest.<anonymous> (/app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/dd-trace/src/exporters/common/request.js:138:7)
    at Object.onceWrapper (node:events:623:26)
    at ClientRequest.emit (node:events:508:28)
    at req.emit (/app/node_modules/.pnpm/dd-trace@5.82.0_@openfeature+core@1.9.1_@openfeature+server-sdk@1.18.0_@openfeature+core@1.9.1_/node_modules/dd-trace/packages/datadog-instrumentations/src/http/client.js:123:25)
    at emitErrorEvent (node:_http_client:108:11)
    at Socket.socketErrorListener (node:_http_client:575:5)
    at Socket.emit (node:events:508:28)

Node.js v24.11.1
[Wed Jan 28 20:33:41 UTC 2026] pnpm exited 1
[Wed Jan 28 20:33:41 UTC 2026] Exiting with status 1

Tracer Config

DD_ENABLE_APM=true
DD_RUNTIME_METRICS_ENABLED=true
DD_PROFILING_ENABLED=true
DD_LOGS_INJECTION=true
DD_LLMOBS_ENABLED=true

Operating System

alpine 3.23

Bundling

No Bundling

[sabrenner]

Hi @ianjkaplan, thanks for opening this issue! To give some context on the behavior here - this is a path we (Datadog LLM Observability) decided on to try and help guide folks who are trying out the product, to make sure that their application is correctly configured to have their LLM data make its way to our product.

I do get that this doesn't extend to well into production if the agent isn't available as soon as the application starts, however. In this case, setting DD_LLMOBS_AGENTLESS_ENABLED=false should resolve this, since we'll take that as the source of truth and assume an agent will be available when submitting data, instead of trying to poll the agent.

I also agree there's something we could do to help clear this up a bit - maybe some better documentation or an additional message in the error. I do think this would be easy enough to just delay ingesting data until an agent is available, but in this case, we wanted to be opinionated as a product about letting users know that they are not configured correctly to send data to us (since a lot of DD LLM Observability extends beyond basic tracing).

Please let me know if part of this explanation doesn't suffice or make sense! And, additionally, if setting the environment variable does not work in your case. We've gotten similar issues in the past, and definitely warrants a documentation change. Also please feel free to ask any more questions 😄

[BridgeAR]

I do believe we can look into the concrete behavior again. Loosing connection and crashing does not sound good, so the original intention of the current behavior is not really matching this.

[ianjkaplan]

Thanks for looking into this. We breifly lost connection to the agent while making some infrastructure changes and this error quickly began to take down every node application process we were running. We did not anticipate that dd-trace would throw an exception after the application already started, so the only thing we can think to do is string match on dd-trace in a top level exception which does not feel like a long term solution. I think other users will run into similar issues.

Maybe there are other ways of surfacing that the agent is unavailable without throwing an exception potentially during a running process outside of a typical execution context like a request handler?

[sabrenner]

@ianjkaplan thanks for providing more context! Let me talk with my team internally just to confirm how we want to handle this kind of case, but I do not disagree with you in your assessments of assumptions 😄 I think from our side we just want to make sure product experiences are aligned. Thank you for your patience here!