Closed wachout closed 3 days ago
@wachout Hello there! I'm here to help you with any bugs, questions, or contributions while you wait for a human maintainer. Feel free to ask me anything!
I found a similar issue where the HTTP node in Dify was not working, but Postman tests were successful. The problem might be related to the timeout settings in Dify. The default configuration for the HTTP request node includes specific timeout values for connection, read, and write operations. If these timeout values are too restrictive, the HTTP request might fail.
Here is the relevant part of the code that sets the default timeout values:
HTTP_REQUEST_DEFAULT_TIMEOUT = HttpRequestNodeTimeout(
connect=dify_config.HTTP_REQUEST_MAX_CONNECT_TIMEOUT,
read=dify_config.HTTP_REQUEST_MAX_READ_TIMEOUT,
write=dify_config.HTTP_REQUEST_MAX_WRITE_TIMEOUT,
)
And the default configuration for the HTTP request node:
@classmethod
def get_default_config(cls, filters: dict | None = None) -> dict:
return {
"type": "http-request",
"config": {
"method": "get",
"authorization": {
"type": "no-auth",
},
"body": {"type": "none"},
"timeout": {
**HTTP_REQUEST_DEFAULT_TIMEOUT.model_dump(),
"max_connect_timeout": dify_config.HTTP_REQUEST_MAX_CONNECT_TIMEOUT,
"max_read_timeout": dify_config.HTTP_REQUEST_MAX_READ_TIMEOUT,
"max_write_timeout": dify_config.HTTP_REQUEST_MAX_WRITE_TIMEOUT,
},
},
}
Ensure that the timeout values in dify_config
are set appropriately and are not too restrictive for the HTTP requests you are making. Adjusting these values might resolve the issue [1].
The default values for these timeouts are:
HTTP_REQUEST_MAX_CONNECT_TIMEOUT
: 300 secondsHTTP_REQUEST_MAX_READ_TIMEOUT
: 600 secondsHTTP_REQUEST_MAX_WRITE_TIMEOUT
: 600 seconds [2][3].To continue talking to Dosu, mention @dosu.
Self Checks
Dify version
0.8.3
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
The http node cannot be used. postman tests can be used.
✔️ Expected Behavior
No response
❌ Actual Behavior
No response