The Dify conversation message API indeed does not throw an error when parameters are missing under streaming mode.

[blackheyan]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

If you call the conversation API and omit certain required parameters, and the response mode is streaming, Dify will not return an error; instead, the request will hang indefinitely. like this image。 And if i set response_mode blocking , i can get an error message. My version is 3.9.5.

[dosubot[bot]]

@blackheyan This is a real bug rooted in how Dify's streaming architecture handles validation errors.

Root cause: For ADVANCED_CHAT and WORKFLOW apps in streaming mode, execution is dispatched to a Celery worker after the SSE response has already been committed to the client [1]. Input validation — specifically BaseAppGenerator._validate_inputs(), which raises ValueError when a required variable is missing — only runs inside that worker. By that point, the HTTP layer can no longer map the error to a proper 400 response, so the SSE connection hangs until the idle timeout (~300s) [2].

In blocking mode, the generator runs synchronously in the request thread, so the ValueError bubbles up through the controller's try/except and is returned as a normal HTTP error [3] — which is why you see the error message with response_mode=blocking.

Same root pattern: This matches the conversation_id hang that was reported in #38800 and fixed by adding eager pre-validation before the streaming task is dispatched — you can see the eager ConversationService.get_conversation() call that was added in the chat controller. Required input validation doesn't have an equivalent eager check yet.

Workarounds:

• Use response_mode=blocking to get proper error responses.
• Call the Get App Parameters endpoint first to discover which variables are required, and validate your inputs client-side before calling the conversation API.

Fix direction: The proper fix would mirror that conversation_id pattern — eagerly validate required inputs in the controller or service layer before the streaming task is dispatched, so the error can be returned as a clean HTTP 400. This would likely target api/services/app_generate_service.py or the controller layer in api/controllers/service_api/app/completion.py.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[blackheyan]

When does Dify plan to fix this issue?

@dosu