fix(llmobs): capture reasoning_content from streamed chat completions by Yun-Kim · Pull Request #18274 · DataDog/dd-trace-py

Yun-Kim · 2026-05-27T00:24:29Z

Summary

The OpenAI + Litellm streamed-chunk aggregator openai_construct_message_from_streamed_chunks never read delta.reasoning_content from streamed chunks, so OpenAI-compatible reasoning providers (DeepSeek-V3/V4, Qwen reasoning models on Baseten/Fireworks, etc.) had their reasoning text silently dropped on the LLM Obs span.

Both the OpenAI and LiteLLM integrations call this aggregator (ddtrace/contrib/internal/openai/utils.py:151, ddtrace/contrib/internal/litellm/utils.py:55) for streamed chat responses and pass the result straight to openai_set_meta_tags_from_chat, which already checks for reasoning_content messages but reasoning content messages were never constructed from the streamed response.

The fix checks for and accumulates delta.reasoning_content message chunks.

Notes for reviewers

The OpenAI Python SDK does not declare reasoning_content as a typed field on ChoiceDelta, but its BaseModel is configured with extra="allow" so the field passes through as an attribute when emitted by an OpenAI-compatible provider. LiteLLM's Delta type exposes reasoning_content directly.
Avoiding an E2E regression test for now because I don't have a deepseek API key 😢 but the unit tests should be sufficient to get this fix out.

Claude session: 948c6399-4afc-4ad8-acfc-d05db310902d
Resume: claude --resume 948c6399-4afc-4ad8-acfc-d05db310902d

The streamed-chunk aggregator never read delta.reasoning_content, so OpenAI-compatible reasoning providers (DeepSeek, Qwen, etc.) had their reasoning text silently dropped on the LLM Obs span while reasoning_output_tokens was still reported. Add the missing accumulation; downstream openai_set_meta_tags_from_chat already emits the role: "reasoning" output message when the key is present. Fixes #18257 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

cit-pr-commenter-54b7da · 2026-05-27T00:25:37Z

Codeowners resolved as

ddtrace/llmobs/_integrations/utils.py                                   @DataDog/ml-observability
releasenotes/notes/fix-llmobs-streamed-reasoning-content-0da3242ccfaa6063.yaml  @DataDog/apm-python
tests/llmobs/test_integrations_utils.py                                 @DataDog/ml-observability

datadog-official · 2026-05-27T00:27:21Z

Tests

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 8 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-py | build linux serverless: [amd64, cp315-cp315, v113741238-d2b8243-manylinux2014_x86_64, 1]

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.
NotImplementedError: This version of CPython is not supported yet

DataDog/apm-reliability/dd-trace-py | build linux serverless: [amd64, cp315-cp315, v113741491-d2b8243-musllinux_1_2_x86_64, 1]

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.
NotImplementedError: This version of CPython is not supported yet

DataDog/apm-reliability/dd-trace-py | build linux serverless: [arm64, cp315-cp315, v113741357-d2b8243-manylinux2014_aarch64, 1]

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.
NotImplementedError: This version of CPython is not supported yet during ddtrace import.

View all 8 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 9b071db | Docs | Datadog PR Page | Give us feedback!}

Address review feedback: initialize reasoning_content as empty string and pop if still empty at the end, matching how tool_calls is handled in the same function. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Match the chunk_content pattern on the adjacent line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ncybul

Nice, thanks for fixing!

Yun-Kim · 2026-05-27T16:46:02Z

/merge

gh-worker-devflow-routing-ef8351 · 2026-05-27T16:46:07Z

View all feedbacks in Devflow UI.

2026-05-27 16:46:06 UTC ℹ️ Start processing command /merge

2026-05-27 16:46:12 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 56m (p90).

2026-05-27 17:27:00 UTC ❌ MergeQueue: The checks failed on this merge request

Tests failed on this commit b0b5498:

What to do next?

Investigate the failures and when ready, re-add your pull request to the queue!
If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
Any question, go check the FAQ.

github-actions · 2026-05-27T16:46:42Z

This change is marked for backport to 4.9 and it does not conflict with that branch.
The command used to test backporting was

git checkout 4.9 && git cherry-pick -x --mainline 1 853bc88ecb986f29cc2bbdedd5ef92f590da22b8

github-actions · 2026-05-27T16:46:43Z

This change is marked for backport to 4.8 and it does not conflict with that branch.
The command used to test backporting was

git checkout 4.8 && git cherry-pick -x --mainline 1 853bc88ecb986f29cc2bbdedd5ef92f590da22b8

Yun-Kim · 2026-05-27T17:59:42Z

/merge

gh-worker-devflow-routing-ef8351 · 2026-05-27T17:59:47Z

View all feedbacks in Devflow UI.

2026-05-27 17:59:46 UTC ℹ️ Start processing command /merge

2026-05-27 18:00:00 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

2026-05-27 18:12:11 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in main is approximately 56m (p90).

2026-05-27 18:51:30 UTC ℹ️ MergeQueue: This merge request was merged

…#18274) ## Summary Fixes #18257. The OpenAI + Litellm streamed-chunk aggregator `openai_construct_message_from_streamed_chunks` never read `delta.reasoning_content` from streamed chunks, so OpenAI-compatible reasoning providers (DeepSeek-V3/V4, Qwen reasoning models on Baseten/Fireworks, etc.) had their reasoning text silently dropped on the LLM Obs span. Both the OpenAI and LiteLLM integrations call this aggregator (`ddtrace/contrib/internal/openai/utils.py:151`, `ddtrace/contrib/internal/litellm/utils.py:55`) for streamed chat responses and pass the result straight to `openai_set_meta_tags_from_chat`, which already checks for `reasoning_content` messages but reasoning content messages were never constructed from the streamed response. The fix checks for and accumulates `delta.reasoning_content` message chunks. ## Notes for reviewers - The OpenAI Python SDK does not declare `reasoning_content` as a typed field on `ChoiceDelta`, but its `BaseModel` is configured with `extra="allow"` so the field passes through as an attribute when emitted by an OpenAI-compatible provider. LiteLLM's `Delta` type exposes `reasoning_content` directly. - Avoiding an E2E regression test for now because I don't have a deepseek API key 😢 but the unit tests should be sufficient to get this fix out. Claude session: `948c6399-4afc-4ad8-acfc-d05db310902d` Resume: `claude --resume 948c6399-4afc-4ad8-acfc-d05db310902d` Co-authored-by: yun.kim <yun.kim@datadoghq.com> (cherry picked from commit b4420fa) Co-authored-by: Yun Kim <35776586+Yun-Kim@users.noreply.github.com>

… [backport 4.9] (#18287) Backport #18274 to 4.9 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Yun Kim <35776586+Yun-Kim@users.noreply.github.com>