Web App: submitting a Human Input form returns 404 “Form not found” and the run stays paused (regression in 1.19.0)

快速结论：该问题通常发生在 Dify 自托管 Web App 中运行含 Human Input 节点的 Chatflow，用户提交表单时触发。优先排查提交请求所用的 form_token 是否被错配为内部 BACKSTAGE 类型令牌，而不是公开 Web App 应有的 STANDALONE_WEB_APP 令牌。

适用环境：Dify 1.19.0，Self Hosted（Docker）。Issue 明确说明同一应用与步骤在 1.18.0 正常，升级到 1.19.0 后复现，且在 3 个不同的 Chatflow 应用上均可复现。未提供操作系统、Python、CUDA、显卡等环境信息。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的排查方法是：对失败 POST 中使用的 token 做一次只读数据库查询，确认其 recipient_type。

注意事项：不要直接删除公开表单端点的 recipient 类型校验。该公开端点会拒绝非公开类型令牌，是有意限制；移除它可能使内部审批令牌暴露在未认证端点上，需由维护者修复。

问题场景

在 Dify 1.19.0 自托管（Docker）环境中，发布一个包含 Human Input 节点的 Chatflow，且该节点的投递方式包含 Web App，并配置了输入字段和操作按钮。通过 Web App 地址（/chat/<app code>）而非调试预览或 Explore 打开应用，发送消息使运行到达 Human Input 节点后，填写表单并点击提交按钮，浏览器发出 POST /api/form/human_input/<form_token>，提交失败，运行保持 paused。

报错原文

Web App: submitting a Human Input form returns 404 "Form not found" and the run stays paused (regression in 1.19.0)

POST /api/form/human_input/<form_token>
HTTP 404
NotFoundError("Form not found")

原因分析

Issue 作者基于 1.19.0 源码提出的可能原因（尚未在数据库层面完全确认）是：

1.19.0 中公开 Web 表单端点只接受 STANDALONE_WEB_APP、EMAIL_MEMBER 和 EMAIL_EXTERNAL 类型的 recipient，其他类型直接返回 404 “Form not found”。
运行时表单在设置了 invoke_source 时会额外添加 BACKSTAGE recipient，因此 Web App 运行的表单同时拥有 STANDALONE_WEB_APP 和 BACKSTAGE 两个 recipient。
在决定把哪个 recipient 的 form_token 放进流式响应或暂停原因时，invoke_from 只映射了 SERVICE_API 和 OPENAPI，WEB_APP 未映射，surface 为 None。
surface 为 None 时，令牌按全局优先级 BACKSTAGE > CONSOLE > STANDALONE_WEB_APP 选取，于是 BACKSTAGE 令牌被交给 Web App，提交时被公开端点拒绝。

评论进一步指出：如果数据库查询返回 backstage，则可确认提交的 token 命中了公开端点的 recipient 拒绝逻辑，从而同时解释 404 与运行不恢复；若返回 standalone_web_app，则该令牌选取解释无法覆盖此次拒绝。

环境排查

确认 Dify 版本是否为 1.19.0，以及是否由 1.18.0 升级而来。
确认部署方式为 Self Hosted（Docker）。
确认应用为 Chatflow，Human Input 节点投递方式包含 Web App。
确认访问入口为 Web App（/chat/<app code>），而非调试预览或 Explore。
确认升级后是否可在多个应用中复现（Issue 中为 3 个应用）。
Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息，无需在此推断。

解决步骤

从失败的 POST /api/form/human_input/<form_token> 请求中取出 form_token，仅在本地使用，不要公开分享该 token。

对该 token 执行只读数据库查询，仅查看返回的 form_id 和 recipient_type：

SELECT form_id, recipient_type
FROM human_input_form_recipients
WHERE access_token = '<token from the failing POST>';

若 recipient_type 为 backstage，则与源码分析一致：Web App 收到了内部类型的令牌，公开端点明确拒绝该类型，因此返回 404 且运行不恢复。这是一种可优先尝试的确认路径，并非已验证的官方修复。
若 recipient_type 为 standalone_web_app，则令牌选取解释不成立，需要另行排查公开端点拒绝该令牌的其他原因。
不要将删除公开端点 recipient 校验作为绕过方案；这可视为限制性措施，Issue 已明确该校验用于保护未认证端点。
在维护者发布修复前，可考虑回退到 1.18.0 作为临时规避（Issue 报告 1.18.0 正常），但回退属于运维决策，需评估数据与升级兼容性，Issue 未验证回退步骤。

验证方法

修复或规避后，重新通过 Web App 打开同一 Chatflow，发送消息到达 Human Input 节点，填写并提交表单；确认浏览器 POST /api/form/human_input/<form_token> 返回 200，表单提交被接受，且原本处于 paused 的运行从 Human Input 节点恢复继续执行。分享排查结果时只提供返回的 recipient_type，不要公开 token 或未脱敏的请求 URL。