Langfuse v4 events_only mode silently drops all Dify traces (legacy ingestion API)

快速结论：在 Langfuse v4 自托管实例启用 events_only 写入模式后，Dify 1.17.x 的 Langfuse 追踪看不到任何记录：Dify 仍调用旧版 ingestion 接口，批量请求返回 207，但逐条事件被 400 拒绝，Dify 侧不报错，追踪被静默丢弃。优先确认 Langfuse 的 v4 写入模式与 Dify 使用的上报接口。

适用环境：Dify 1.17.0（也复现于当时的 main 分支）、1.17.1（Dify Cloud 侧有独立确认）；自托管方式为 Docker/Helm；Langfuse 自托管 v4，实测版本 4.10–4.18；另有 Langfuse Cloud US 区域 v4.70.0 的确认。Issue 中未给出 Python、CUDA、显卡等信息。

最快修复方案：暂无确认的一步修复方案。Issue 作者称已有基于 Langfuse Python SDK v4 的 OpenTelemetry 路径（/api/public/otel）的可用实现，并在 Langfuse 4.18 的 events_only + direct 下覆盖全部七种追踪流程验证通过，但对应 PR 仍在后续提交中，Issue 讨论里没有可执行的配置项。

注意事项：把 Langfuse 切回 dual 写入模式可以让追踪重新出现，但会持续双写 ClickHouse，且官方将其定位为迁移过渡状态而非最终状态，只能作为临时缓解。新写入路径还涉及两个约束：SDK 没有公开 API 设置追溯的 span 起始时间，需要在后置记录时用 tracer 创建原始 OTel span；为保留 Dify 按消息/工作流运行/节点执行 ID 做 upsert 的确定性 trace 与 observation ID，需要自定义 OTel id generator。Langfuse 官方表示旧 API 存在硬性截止时间，接入方需尽快迁移。

问题场景

用户自托管 Langfuse v4，按文档配置最终形态：LANGFUSE_MIGRATION_V4_WRITE_MODE=events_only（默认值）、LANGFUSE_MIGRATION_V4_NATIVE_OTEL_BEHAVIOUR=direct，然后在 Dify 中为任意应用启用 Langfuse 追踪并运行对话或工作流，结果在 Langfuse 中完全查不到 trace。同样的问题在 Dify Cloud 1.17.1 + 新建的 Langfuse Cloud 组织上也复现：项目认证返回 HTTP 200，手工发送的 trace-create 批处理返回 207 但 successes 为空、每条事件被 400 拒绝；而单独发往 /api/public/otel/v1/traces 的 OTLP 测试请求可以成功写入并能在 Observations API v2 中读取。

报错原文

Langfuse v4 events_only mode silently drops all Dify traces (legacy ingestion API)

POST /api/public/ingestion -> HTTP 207
successes: []
per-event 400: legacy trace/observation writes are no longer accepted for this organization

原因分析

Dify 的 Langfuse provider（api/providers/trace/trace-langfuse/src/dify_trace_langfuse/langfuse_trace.py）把所有写入都作为旧版批事件（IngestionEvent_TraceCreate / SpanCreate / GenerationCreate）发送到 POST /api/public/ingestion。按 Langfuse v3→v4 迁移指南，在 events_only 模式下该接口仍返回 207，但对除 score-create/sdk-log 之外的所有事件类型逐条返回 400，因此 Dify 的写入被按事件拒绝，而批量调用本身显示”成功”，导致 trace 被静默丢弃、Dify 侧不报错。v4 唯一受支持的写入路径是 Python SDK v4 的 OpenTelemetry 路径（/api/public/otel）。1.17.1 的 Langfuse provider 仍在使用 ingestion.batch，这是问题在 Cloud 端同样出现的原因。

环境排查

确认 Dify 版本：1.17.0 与 1.17.1 均已复现，升级小版本不能解决。
确认 Langfuse 部署形态与版本：自托管 v4（4.10–4.18 实测）或 Langfuse Cloud v4（US 区域 v4.70.0 确认）。
确认 Langfuse 的 v4 写入模式：LANGFUSE_MIGRATION_V4_WRITE_MODE 是否为 events_only，LANGFUSE_MIGRATION_V4_NATIVE_OTEL_BEHAVIOUR 是否为 direct。
确认 Dify 侧 Langfuse provider 是否已启用、项目凭据认证是否成功（HTTP 200 并不代表写入成功）。
Issue 中未提供 Python、CUDA、PyTorch、显卡或节点依赖信息，暂不需要列入排查。

解决步骤

先确认问题范围：在 Dify 中运行一次对话或工作流，然后在 Langfuse 中检索对应 trace。若完全无记录且 Dify 无报错，与本 Issue 现象一致。
检查 Langfuse 的写入模式配置。若处于 events_only，可优先尝试临时改回 dual 写入模式，确认追踪能恢复，以此验证问题来自写入路径不兼容而非凭据或网络。
如需在不变更 Dify 代码的前提下做连通性判断，可参考 Issue 评论中的做法：用相同凭据分别向 /api/public/ingestion 和 /api/public/otel/v1/traces 发送诊断请求。前者返回 207 但 successes 为空、事件级 400，后者成功，即说明需要 OTel 路径。注意这类探测是独立测试，不等同于 Dify 的实际执行。
长期方案是等待或采用 Dify 的 Langfuse provider 迁移到 Langfuse Python SDK v4 的 OpenTelemetry 写入路径。Issue 作者称已有实现并将在 PR 中提交；在官方版本发布前，不建议自行拼凑未发布代码作为生产方案。
由于 Langfuse 官方已给出旧 API 的硬性截止时间，部署计划中应预留升级 Dify 或 Langfuse provider 的时间窗口，而不是长期依赖 dual 模式。

验证方法

在 Dify 中运行一次对话或工作流后，到 Langfuse 平台检索对应的 trace，确认消息、工作流、工具、审核、数据集检索、建议问题、会话名生成等类型的事件均可见。若采用 OTel 诊断请求，应能在 Observations API v2 中读取到该测试记录。追踪恢复且 Dify 日志中不再出现被拒绝的批写入，即可认为问题已解决。