[bot] OpenAI-compatible chat completions streaming drops `reasoning_content` (affects DeepSeek and other providers using the plain OpenAI SDK)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 65/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- javascript, typescript
调研方向
The issue is in js/src/instrumentation/plugins/openai-plugin.ts. Start by examining the aggregateChatCompletionChunks function and the AggregatedChatChoice and toChatChoice types. Compare with the fixed implementations in groq-plugin.ts and openrouter-plugin.ts to understand the pattern for adding reasoning content aggregation. The goal is to modify the shared function to read delta.reasoning, delta.reasoning_content, or delta.reasoning_details and include them in the aggregated output. Test by simulating a streaming response from an OpenAI-compatible provider like DeepSeek.
由索引模型根据 Issue 内容生成。
描述
Summary
The shared streaming aggregation function used by the plain OpenAI plugin (aggregateChatCompletionChunks in js/src/instrumentation/plugins/openai-plugin.ts) does not capture reasoning/reasoning_content/reasoning_details fields from chat-completions streaming deltas. This function is the base implementation used directly by the OpenAI chat.completions.create channel — the exact code path exercised whenever a user points the vanilla openai npm package at a custom baseURL, which is DeepSeek's own documented integration method (and a common pattern for other OpenAI-compatible inference providers/self-hosted reasoning models). Reasoning content emitted during streaming by these providers is silently dropped from spans.
This is the same class of bug already found and fixed three times in sibling/downstream plugins — Mistral (#1857, fixed), OpenRouter (#1883, fixed), and Groq (#1911, fixed) — but in each of those fixes, the shared base function itself was left untouched, so the gap persists for any consumer that reaches it directly (i.e. the plain OpenAI SDK against a third-party OpenAI-compatible endpoint).
What instrumentation is missing
Streaming aggregation never reads reasoning fields
In js/src/instrumentation/plugins/openai-plugin.ts:
AggregatedChatChoice(lines 408–420) has fields forrole,content,refusal,audio,toolCallsByIndex,logprobs, andfinish_reason— no field for reasoning content.aggregateChatCompletionChunks(lines 459 onward) readsdelta.finish_reason,delta.role,delta.content,delta.refusal, anddelta.audio(lines 505–534+) — there is no branch readingdelta.reasoningordelta.reasoning_content.toChatChoice(lines 435–452) builds the final aggregated message fromrole,content,refusal,audio,tool_callsonly.
A repo-wide check confirms this: js/src/instrumentation/plugins/openai-plugin.ts has zero occurrences of "reasoning" (case-insensitive). By contrast, js/src/instrumentation/plugins/groq-plugin.ts (lines 680–720) wraps this exact shared function with an additional aggregateGroqReasoning post-processing step specifically because the shared function doesn't handle it — direct proof the underlying gap was deliberately routed around for Groq's fix rather than fixed at the source, leaving it open for every other consumer of the shared function.
Vendor types have no typed reasoning field either
js/src/vendor-sdk-types/openai-common.ts, OpenAIChatDelta (lines 135–143):
interface OpenAIChatDelta {
role?: string;
content?: string;
refusal?: string;
audio?: OpenAIChatAudio | null;
tool_calls?: OpenAIChatToolCallDelta[];
finish_reason?: string | null;
[key: string]: unknown;
}
The [key: string]: unknown index signature means the runtime value is present on delta when a provider sends it, but the aggregation code never reads it.
Non-streaming path is unaffected
The non-streaming chatCompletionsCreate handler (openai-plugin.ts lines 89–109) uses extractOutput: (result) => result?.choices, a full passthrough — so message.reasoning_content survives for non-streaming calls. The gap is specific to streaming aggregation.
Upstream API format
DeepSeek's chat completions API (OpenAI-compatible, accessed via the plain openai SDK with a custom baseURL per DeepSeek's own quickstart) returns chain-of-thought content in thinking-enabled models via a reasoning_content field at the same level as content. In streaming responses this is delta.reasoning_content, a nullable string emitted incrementally in chat.completion.chunk objects, analogous to how delta.content streams the final answer.
- DeepSeek API reference: https://api-docs.deepseek.com/api/create-chat-completion
- DeepSeek Thinking Mode guide: https://api-docs.deepseek.com/guides/thinking_mode/
This same non-standard reasoning/reasoning_content/reasoning_details extension pattern is also what OpenRouter (#1883) and Groq (#1911) needed dedicated fixes for — it is a broadly used convention among OpenAI-compatible providers, not unique to one vendor.
Comparison with other providers in this repo
| Provider | Reasoning content captured in streaming |
|---|---|
| Anthropic | thinking_delta aggregated |
| Google GenAI | thought parts handled |
| AI SDK | reasoning-delta chunks aggregated |
| Cohere | thinking content blocks aggregated |
| Mistral | thinking chunks aggregated — fixed in #1857 |
| OpenRouter | reasoning/reasoning_content/reasoning_details aggregated — fixed in #1883 |
| Groq | reasoning aggregated via dedicated wrapper — fixed in #1911 |
OpenAI base plugin (chat.completions.create) |
Silently dropped — this issue |
Braintrust docs status
not_found — checked https://www.braintrust.dev/docs/integrations/ai-providers/openai. The page documents metrics like completion_reasoning_tokens (a token count) and covers pointing the OpenAI client at a custom API base URL/endpoint path, but does not mention reasoning_content capture or DeepSeek/OpenAI-compatible reasoning-content streaming at all.
Local files inspected
js/src/instrumentation/plugins/openai-plugin.ts(lines 89–109: non-streaming passthrough is fine; lines 408–452:AggregatedChatChoice/toChatChoicehave no reasoning field; lines 459–534+:aggregateChatCompletionChunksnever readsdelta.reasoning/delta.reasoning_content)js/src/instrumentation/plugins/openai-channels.ts(chatCompletionsCreatechannel definition)js/src/vendor-sdk-types/openai-common.ts(lines 135–143:OpenAIChatDeltahas no typed reasoning field)js/src/instrumentation/plugins/groq-plugin.ts(lines 680–720: proof pattern — Groq wraps the shared function with its ownaggregateGroqReasoningrather than the shared function being fixed)js/src/instrumentation/plugins/openrouter-plugin.ts(confirmed sibling plugin's own separateaggregateOpenRouterChatChunkshas equivalent handling, unrelated to the shared OpenAI function)
- 主要语言
- TypeScript
- 星标
- 29
- 派生
- 18
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 69
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
braintrustdata/braintrust-sdk-javascript 的其他 Issue
-
High TypeScript checking cost from generated Zod 3 schemas可能已有人在做 @lforst 于 3 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 22/100
braintrustdata/braintrust-sdk-javascript#2624 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
[bot] Instrument Luma AI (17,324 weekly downloads)可能已有人在做 @karthiksenv 于 2 天前认领。 未关闭typescript
难度 4/5 3-5 天 新手友好度 55/100
braintrustdata/braintrust-sdk-javascript#2578 ·
维护者通常 1 天内回复
-
[bot] Instrument Letta Agent SDK (87,205 weekly downloads)可能已有人在做 @karthiksenv 于 6 天前认领。 未关闭typescript
难度 4/5 3-5 天 新手友好度 55/100
braintrustdata/braintrust-sdk-javascript#2577 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
braintrustdata/braintrust-sdk-javascript#2527 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 65/100
braintrustdata/braintrust-sdk-javascript#2526 ·
维护者通常 1 天内回复
查看 braintrustdata/braintrust-sdk-javascript 的全部 Issue
相似的 Issue
-
freshness freshness:observed-only
难度 2/5 1-3 小时 新手友好度 68/100
thoroc/context-radar#280 ·
-
难度 2/5 1-3 小时 新手友好度 66/100
-
documentation story
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
bug category:billing priority:p3 track:fast
难度 2/5 1-3 小时 新手友好度 72/100
LanternOps/breeze#9223 ·
维护者通常 1 天内回复