Skip to content

feat(obs): Opik create/span 批量上报队列 - #1310

Draft
cjl-ux wants to merge 44 commits into
TencentCloud:feat/server_teamfrom
cjl-ux:feat/opik-batch-queue
Draft

cjl-ux wants to merge 44 commits into
TencentCloud:feat/server_teamfrom
cjl-ux:feat/opik-batch-queue

Conversation

@cjl-ux

@cjl-ux cjl-ux commented Sep 9, 2026

Copy link
Copy Markdown

⚠️ 本支已被 #1328 包含(提交链 2f295e7 → ef04e0c → ac87b69 → 50f36f4 → c0c4ab6 → ae668aa1)。按下面的「合入顺序」只需合 #1328;本 PR 已转 draft,保留仅用于逐层评审。

Opik 第 4 层:create trace / create span 批量上报,update 走同一条 FIFO 保序。

上报量上来之后先解决压力,但顺序不能破坏——一旦批量请求晚于更新请求抵达,后端会丢弃对尚不存在 trace 的更新,表现是"trace 在,但没有结束时间与用量"。

改动

位置 内容
src/opik.ts create trace / create span 的连续同型条目合并为 /batch 请求;update trace 无批量端点,仍逐条发送
同上 两类请求共用同一条内存 FIFO:批量化只改变"一次发送几条",不改变"谁先谁后"
同上 老版本后端返回 404 / 405 时逐条回退,回退路径同样经过该队列
  • 本 PR 净增量+381 / −25(7 个文件)。页面显示的 +4,196 里含前三层带入的内容。

验证

  • npx tsc --noEmit → 0 错误
  • npm test3 文件 / 35 用例全过(含批量合并、顺序保持、回退路径)

边界

  • 队列在进程内存中,进程退出时未 flush 的条目会丢——观测数据的取舍,不影响业务。

合入顺序(本批 13 支)

#1326(基线类型修复 + CI 门禁,最先)→ 协议 #1226 → #1253 → 接入 #1334 → #1325 → Opik #1270 → #1307 → #1309 → #1310 → #1328#1251#1346#1347 与其它支无文件交集,任意时间合。

cjl-ux and others added 30 commits September 6, 2026 04:29
…逐字节一致)

- anthropicHandler/codexHandler/handler/workbuddyHandler:SessionInfo 断言、
  resetFlow 等上游 base 既有类型错误修复
- cost-guard.d.ts:声明 @context-proxy/cost-guard 模块,解决 workspace
  依赖解析
- memory-bridge:SessionIdFields.agent_source 字段对齐
- 先合入 TencentCloud#1226/TencentCloud#1251 时本部分 diff 自动为空,Opik PR 可独立全量 tsc 0
- 统一 sendOpikRequest:单次超时(opik.timeoutMs,默认 2000ms)、
  连续失败 5 次熔断 30s、同类错误 10s 限频一条 warn
- REST 前缀可配置:opik.apiPrefix(backend /v1/private,前端 /api/v1/private)
- 新增 opik.test.ts 9 例
- buildAuditPayload 纯函数化、长度封顶、trace_id 保留完整值
- JSONL 落盘大小轮转(AUDIT_LOG_FILE / AUDIT_LOG_MAX_BYTES)
- recorder 审计 target 去掉上游基线不存在的 threadId 引用
- 新增 audit.test.ts 3 例
- 新增 opik-metadata.ts:字段白名单/长度封顶组装 metadata,
  summarizeToolInteraction 兼容 OpenAI/Anthropic/legacy 工具形态
- handler/anthropic create trace 与非流式 span 挂载 metadata
- 新增 opik-metadata.test.ts 6 例
- injection pipeline.processWithStats 透出本轮 HookResult[],process() 保持兼容包装
- opik-metadata.buildMemoryInjectionContext:memory_injection 增加 hook_count / block_count / error_count / hooks(逐钩子明细;错误只落布尔位,hooks 上限 20)
- 四个 handler(Chat / Anthropic / Codex / WorkBuddy)统一接线
- deploy/opik-compose.yml + deploy/opik-assets:自托管 Opik 栈(docker compose config 校验通过)
- deploy/global-images/start-proxy.sh 支持 PROXY_OPIK_* 透传写 opik 段;.env.example 补示例(bash -n 通过)
- 设计文档与实现同步;tsc 0、vitest 31/31、四合一 240/240
cjl-ux and others added 11 commits September 10, 2026 19:37
- opik.ts 新增 opikTurnTraceId(sessionKey, turnSeq):由 (sessionKey, turnSeq) 派生稳定 UUIDv7
- 四个 handler 主 trace 改用确定性 traceId,工具循环的多条 HTTP 请求共享同一条 trace,LLM 调用仍作为独立 span 挂在其下
- 本机 Opik 实测:同 ID 重复 POST 幂等、多 span 同 trace 正常、并发 PATCH 不损坏数据
- 设计文档与 opik 单测同步:tsc 0、vitest 25/25
统一调整本层新增代码的位置,不改任何已有逻辑,也不改变任何既有行:
- Chat / Anthropic 流式错误分支:reportXxxOpikFailure 调用从 pipe.streamDone()
  之后移到 langfuseReportFailure 之前,与其它失败上报并列;
- workbuddyHandler:reportWorkbuddyOpikFailure 帮助函数移到文件末尾(函数声明
  提升,调用点不变),原位置留白与三方合并基准逐字节对齐。

原因:这几处原先与 TencentCloud#1253(协议接线:删除本地 filterResponseHeaders、改写同一
错误分支)落在同一锚点,两条分支无论谁先合都会产生冲突块。

验证:npx tsc --noEmit 0 错误;npx vitest run 30/30 通过;
对 merge-base 220af62TencentCloud#1253 的三方合并预演:0 冲突。
沿用父层 TencentCloud#1309 的重排,并额外把 flushOpikBatchQueue 的 import 放到 langfuse
import 之后(遥测类 import 归组),不再与 TencentCloud#1253 新增的 applyAutoDetect import
抢同一个插入点。纯位置调整,无逻辑变化。

验证:npx tsc --noEmit 0 错误;npx vitest run 35/35 通过;
对 merge-base 220af62TencentCloud#1253 的三方合并预演:0 冲突。
@cjl-ux

cjl-ux commented Sep 12, 2026

Copy link
Copy Markdown
Author

转 draft 说明:本支的内容已被 #1328 包含(提交链 2f295e7 → ef04e0c → ac87b69 → 50f36f4),按本支 body 里的「合入顺序」只需合上层那一支即可。

本批 13 支里有 4 支是堆叠链的中间层,页面 diff 只能显示相对公共祖先的累计值(跨 fork 无法把 base 指向前一层),留着 ready 会让评审者把同一份代码读多遍。因此本 PR 转 draft 保留逐层评审用——若内审希望按层逐个合入,重新标记为 ready 即可。

cjl-ux added a commit to cjl-ux/TencentDB-Agent-Memory that referenced this pull request Sep 12, 2026
单独执行 check-doc-claims.mjs 时会读到工作区里残留的 .vitest-report.json(例如在 TencentCloud#1270/TencentCloud#1307/TencentCloud#1309/TencentCloud#1310 这类没有 posttest 的分支跑完 npm test 之后),结果是「核对 7 条、跳过 30 条」式假通过:故意把 role-rules 的 25 改成 26 仍然报通过。改为只有 posttest 阶段(同一轮 npm test 刚写出报告)才信任该文件,其余情况先删除再自己跑一次 vitest。

矩阵文档:补回 TencentCloud#1253 引入的 upstream-auth.test.ts 行,并把「协议接线分支额外测试」的聚合数由 13/164 更正为 14/175(两支合并 15/189 已实测无误)。
@cjl-ux

cjl-ux commented Sep 12, 2026

Copy link
Copy Markdown
Author

正文更正:按当前 head 重新实合复核,共享段落里的「冲突面共 4 个文件」更正为 3 个文件——scripts/qa/check-doc-claims.mjs 现已在 #1226 / #1253 / #1328 三支逐字节同步(blob f4aa8815),不再产生冲突;另两处(package.json 取并集、矩阵文档与 role-rules 测试取 #1226 一侧)口径不变。全批合入态:tsc --noEmit 0 错误、37 文件 / 394 用例、文档校验 38 条通过。

@cjl-ux
cjl-ux marked this pull request as ready for review September 12, 2026 02:40
@cjl-ux
cjl-ux marked this pull request as draft September 12, 2026 03:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants