bug:

快速结论：这是 Langfuse V3 Preview（内部称 V4 Beta / Fast 模式）UI 的已知缺陷，不是数据写入问题。优先排查方式是暂时关闭 “Faster Langfuse experience” 开关，回到 Stable UI 查看完整数据。

适用环境：Langfuse Cloud（Issue 未提供自托管版本、Python、CUDA 或显卡信息）。触发场景为通过 REST API（POST /api/public/ingestion）批量写入历史 trace。

最快修复方案：暂无确认的一步修复方案。Dosu 明确提出的可行方案是：在 V3 Preview UI 中关闭 “Faster Langfuse experience” 开关，切换回 Stable UI 即可正常显示 Latency pill 和 Tags。

注意事项：该方案只是绕过而非修复底层缺陷。Tags 在 Fast 模式中当前对所有 trace 都被硬编码为空数组（不仅是 REST API 写入的数据）；Latency 计算依赖 observation 的 endTime 字段，若 REST 请求中未携带该字段，Stable UI 也可能无法计算。

问题场景

用户通过 Langfuse 的 REST API（POST /api/public/ingestion）批量写入带 startTime、endTime 和 tags 数组的历史 trace（例如从 ElevenLabs 等平台回填 5 分钟前的事件）。在开启 V3 Preview “Faster Experience” 后，trace 详情右侧面板的 Latency pill 和 Tags 不渲染，但中间 trace tree 中仍有总耗时显示。切换回 Stable UI 后，Latency 和 Tags 均正常显示。

报错原文

[UI Bug] V3 Preview "Faster Experience" drops Latency pill and Tags for traces ingested via REST API (Works perfectly in Stable)

原因分析

根据 Issue 中的排查结论，这不是 REST API 特有的问题，而是 V3 Preview UI（代码内部称为 V4 Beta / Fast 模式）与 Stable UI 的数据来源不同导致的渲染差异。

可能原因包括：

Fast 模式通过 eventsToTraceAdapter.ts 从 events 表合成 trace 数据，而 Stable UI 直接查询 traces 表。
在 eventsToTraceAdapter.ts 中，tags 字段当前被硬编码为空数组（tags: []），对所有 trace 一律输出空 tags，无论使用 REST API 还是 OTel SDK 写入。
Latency 计算逻辑虽然存在，但依赖 observation 记录的 endTime 字段；如果所有 observation 的 endTime 都为 null，则 Latency pill 不会渲染。

环境排查

确认当前 Langfuse 运行环境为 Langfuse Cloud（Issue 未提供 self-hosted 版本号）。
检查 REST API 写入的 observation 是否包含 endTime 字段。
确认 UI 是否开启了 “Faster Langfuse experience” 预览开关。
若使用 OTel SDK 写入，请对比验证 Fast 模式是否同样缺少 Tags，以排除 REST API 特有问题的可能性。

解决步骤

临时绕行方案（已验证）：在 Langfuse 界面中关闭 “Faster Langfuse experience” 开关，切换回 Stable UI 查看 trace 数据，Latency pill 和 Tags 应正常显示。
检查 REST API 写入数据：确认 trace 创建请求中的 observations 是否带有 endTime 字段。如果 observation 缺少 endTime，应补充该字段后重新入库。
等待官方修复：由于 Tags 在 Fast 模式中被硬编码为空数组，此问题需要 Langfuse 团队在 eventsToTraceAdapter.ts 中移除硬编码逻辑才能根本解决。可关注后续版本更新。