Infinite 404 “Conversation Not Exists” loop still reproducible on v1.15.0 / v1.16.0 (fix from #34731 not merge)

快速结论：这个报错通常出现在 Dify 自托管 Web App（Chatflow 分享链接）场景：浏览器 localStorage 中缓存的 conversation_id 已在服务端失效，前端仍反复请求 /api/messages，于是陷入 Infinite 404 “Conversation Not Exists” loop。优先排查前端是否命中已知未合并修复（#34945），并确认该 conversation_id 是否已失效。

适用环境：Dify v1.15.0（报告者实际复现环境）以及 v1.16.0（报告者确认修复点仍缺失）；Self Hosted（Docker）；浏览器前端 Web App 嵌入链接 /chatbot/<token>。Issue 中未提供 Python、CUDA、PyTorch、显卡等信息，不做补充。

最快修复方案：暂无确认的一步修复方案。Issue 已明确：直接修复 PR #34945（在 useShareChatList 中识别 404、调用 removeConversationIdInfo()、并对 404 设置 retry: false）仍未合并，未进入任何 release。

注意事项：“Reset conversation”按钮在该版本中不会清除 localStorage 条目；#35519（URL 参数优先于 localStorage）与 #38801（后端无效 ID 快速失败）已落地，但均未解决纯 localStorage 场景下的无限重试。可优先尝试在浏览器控制台手动清除或覆盖 conversationIdInfo，但这只是用户侧规避，不是产品级修复。

问题场景

在 Self Hosted（Docker）部署的 Dify 中，创建一个 Chatflow 应用，并通过 /chatbot/<token> 嵌入链接以 Web App 形式分享。用户打开该 chatbot 页面并发送消息后，前端会在 localStorage 的 conversationIdInfo 中保存 conversation_id（结构为 { [appId]: { [userId || 'DEFAULT']: conversationId } }）。当这个 conversation_id 在服务端变为失效状态（被删除，或被覆盖为一个不存在的 UUID）后重新加载页面，前端仍带旧 ID 轮询请求 /api/messages，从而触发无限 404 循环。

报错原文

GET /api/messages?conversation_id=xxxxx&limit=20&last_id= HTTP/1.1" 404 201
GET /api/messages?conversation_id=xxxxx&limit=20&last_id= HTTP/1.1" 404 201
GET /api/messages?conversation_id=xxxxx&limit=20&last_id= HTTP/1.1" 404 201
... (repeats every ~2-3 seconds)

{"code":"not_found","status":404,"message":"Conversation Not Exists. You have requested this URI [/api/messages] but did you mean /api/messages or /api/chat-messages or /api/saved-messages?"}

原因分析

最可能的原因是前端缺少针对 404 的恢复路径：useShareChatList 会无限重试（TanStack Query 默认 retry + 窗口聚焦时 refetch），错误状态没有被 hooks 消费，removeConversationIdInfo() 从未被调用，因此失效的 conversation_id 一直留在 localStorage 中。报告者核查 v1.16.0 源码后确认三个修复点仍然缺失：web/service/use-share.ts 的 useShareChatList 没有 404 感知的 retry，web/service/share.ts 的 fetchChatList 未传 silent: true。同一问题即 #34731，虽被关闭为 completed，但其修复并未落地任何 release；后续 PR #34945 存在合并冲突（mergeable_state: dirty）、CI 失败，并被标记 needs-revision，从未合并。

环境排查

确认 Dify 版本：报告在 v1.15.0 复现，并核对 v1.16.0 源码中修复点仍缺失；请确认你是否运行在这两个版本之一。
确认部署方式：Self Hosted（Docker）。
确认应用类型为 Chatflow，并通过 /chatbot/<token> 嵌入链接访问。
在浏览器 DevTools → Application → Local Storage 中检查是否存在 conversationIdInfo，以及其中的 conversation_id 是否指向服务端已不存在的会话。
检查 nginx access log 是否出现每约 2-3 秒一次的 /api/messages ... 404 重复请求。
Python、CUDA、PyTorch、显卡、节点等版本：Issue 未提供，暂不作为排查项。

解决步骤

先确认问题存在：打开 chatbot 页面，在 DevTools Network 中观察 /api/messages 是否持续返回 404；同时在 Local Storage 中确认 conversationIdInfo 里保存的是一个已失效或伪造的 conversation_id。
可优先尝试用户侧规避（不是产品级修复）：在浏览器控制台清除或覆盖该条目，例如 localStorage.setItem('conversationIdInfo', JSON.stringify({ '<app-id>': { DEFAULT: '00000000-0000-0000-0000-000000000000' } })) 或直接删除该 key，然后刷新页面。Issue 明确指出“Reset conversation”按钮不会清除该 localStorage 条目，因此按钮不可依赖。
若你是自托管维护者，可按 PR #34945 的思路应用前端修复：在 useShareChatList 中检测 404 响应、调用 removeConversationIdInfo() 清除失效 ID，并为 404 设置 retry: false。注意该 PR 尚未合并、存在合并冲突与失败 CI，直接采用需自行评估风险，或基于当前 main 重新提交 PR。
不要期待 #35519 或 #38801 能解决本问题：#35519 只让 URL 中的 conversation_id 优先于 localStorage，对纯 localStorage 场景无效；#38801 只是让后端对无效 ID 快速返回 404，不处理前端无限重试。

验证方法

清除或覆盖失效的 conversationIdInfo 后刷新页面，Network 中不再出现反复的 GET /api/messages ... 404，页面能正常开始新会话，即说明本次规避生效。若采用前端修复（对齐 #34945 思路）后，失效 ID 应被自动从 localStorage 移除、请求不再无限重试，并且用户无需手动清理站点数据即可继续对话。