Missing ops trace task when chat message generation fails

快速结论：该报错发生在 Dify 1.15.0 传统 Chatbot/Completion 应用中，当模型供应商返回错误导致消息生成失败时，系统不会发送运维追踪（ops trace）任务。优先排查 EasyUIBasedGenerateTaskPipeline 中 QueueErrorEvent 错误处理路径是否缺少 trace task 入队逻辑。

适用环境：Dify 1.15.0，Self Hosted（Docker 部署），传统 Chatbot 和 Completion 应用类型。

最快修复方案：暂无确认的一步修复方案。根据 Issue 分析，需在 EasyUIBasedGenerateTaskPipeline 的 QueueErrorEvent 处理分支中，在设置消息状态为 ERROR 后、break 之前补充调用 trace_manager.add_trace_task()。

注意事项：该修复仅影响传统 Chatbot/Completion 应用；Advanced Chat 和 Workflow 应用使用 WorkflowPersistenceLayer，不受此问题影响。另需注意相关的 Langfuse 问题（#37824）可能导致即使 trace task 入队成功，非工作流应用的 LLM 生成观测仍会丢失。

问题场景

在 Dify 1.15.0 自托管环境中，启动传统 Chatbot 或 Completion 应用进行对话时，如果模型供应商（LLM provider）返回错误，系统不会发送运维追踪（ops trace）任务。用户期望即使 LLM 返回错误，ops trace 任务仍应正常发送，但实际未发送。

报错原文

Missing ops trace task when chat message generation fails

原因分析

问题根源位于 EasyUIBasedGenerateTaskPipeline（用于 Chat 和 Completion 应用）。当 LLM 错误发生时，事件循环处理 QueueErrorEvent，将消息状态更新为 ERROR，产出错误响应后立即 break 退出循环——这意味着 _save_message() 永远不会被调用，ops trace 任务因此也从未被入队。

相比之下，Advanced Chat 和 Workflow 应用使用 WorkflowPersistenceLayer，该层对所有终止状态（包括 FAILED 和 STOPPED）都会无条件调用 _enqueue_trace_task()。因此该缺陷仅影响传统 Chatbot/Completion 应用类型。

环境排查

确认 Dify 版本是否为 1.15.0（Issue 已确认版本）
确认部署方式为 Self Hosted（Docker）
确认应用类型为传统 Chatbot 或 Completion（非 Advanced Chat/Workflow）
检查 api/core/app/task_pipeline/easy_ui_based_generate_task_pipeline.py 中的 QueueErrorEvent 处理逻辑（约第 271-276 行）
检查 api/core/app/workflow/layers/persistence.py 中的 _enqueue_trace_task() 调用（约第 186-196 行）作为对比参考

解决步骤

定位错误处理路径：打开 api/core/app/task_pipeline/easy_ui_based_generate_task_pipeline.py，找到 QueueErrorEvent 的处理分支（约第 271-276 行）。
参考成功的 trace 入队逻辑：查看 _save_message() 方法中成功路径如何调用 trace_manager.add_trace_task(...)（约第 432-440 行）。

补充错误路径的 trace 入队（可优先尝试）：在 QueueErrorEvent 分支中，设置消息状态为 ERROR 后、break 之前，添加类似以下逻辑：

if trace_manager:
    trace_manager.add_trace_task(
        TraceTask(
            TraceTaskName.MESSAGE_TRACE,
            conversation_id=self._conversation_id,
            message_id=self._message_id,
        )
    )

重启 Dify 服务：修改代码后重启 API 服务使更改生效。
验证修复：复现 LLM 错误场景，确认 ops trace 任务能够正常发送。

验证方法

在修复后的环境中，故意触发模型供应商错误（例如配置错误的 API Key 或不可用的模型），启动 Chat 或 Completion 应用对话。确认消息状态变为 ERROR 的同时，ops trace 任务能够正常入队并发送。可查看日志确认 add_trace_task 被调用，或通过可观测性平台（如 Langfuse、LangSmith 等）确认追踪记录存在。