Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP REQUEST NODE is always waiting but endpoint have responsed #4386

Open
4 tasks done
Albedoww opened this issue May 14, 2024 · 3 comments
Open
4 tasks done

HTTP REQUEST NODE is always waiting but endpoint have responsed #4386

Albedoww opened this issue May 14, 2024 · 3 comments
Labels
🐞 bug Something isn't working

Comments

@Albedoww
Copy link

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • 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).
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.3.21

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

the HTTP REQUEST NODE is always waiting but endpoint have responsed.
i checked the HTTP REQUEST NODE singly running is successful
{128724-x-21020669104275}
qq_pic_merged_1715704379616

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Copy link

dosubot bot commented May 14, 2024

To address the issue where the HTTP REQUEST NODE remains in a waiting state despite the endpoint responding, follow these targeted steps:

  1. Check Response Size Limits: Ensure the response size does not exceed the HttpExecutor class's limits (MAX_BINARY_SIZE for binary files and MAX_TEXT_SIZE for text responses). Adjust the HTTP_REQUEST_NODE_MAX_BINARY_SIZE and HTTP_REQUEST_NODE_MAX_TEXT_SIZE environment variables if necessary.

  2. Review Content-Type Handling: Verify that the response's content type is correctly interpreted by the HttpExecutorResponse class. If the content type is mistakenly identified as a file (image, audio, video), it could lead to issues.

  3. Adjust Timeout Settings: Review the timeout settings (connect, read, write) in the HttpExecutor class to match your endpoint's response times. Incorrect timeout settings can cause the request to hang.

  4. Ensure Correct Variable Parsing: Make sure all variables used in your HTTP request node are correctly defined and accessible in the variable_pool to avoid incomplete or malformed requests.

  5. Validate Request Method: Confirm that the HTTP method used is supported and correctly implemented by the _do_http_request method in HttpExecutor.

  6. Enhance Debugging and Logging: Increase logging within the HttpExecutor class to capture detailed information about the request and response, helping to pinpoint the issue.

  7. Check Network and Endpoint Configuration: Ensure there are no network issues or misconfigurations affecting communication between your self-hosted Dify setup and the endpoint.

  8. Inspect File Handling for Responses: If expecting file returns, verify that multipart/form-data responses are correctly processed, focusing on how files are extracted.

By systematically addressing these areas, you should be able to resolve the issue with the HTTP REQUEST NODE.

Details

Sources


About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

@hjlarry
Copy link
Contributor

hjlarry commented May 15, 2024

@Albedoww please upgrade the latest version to see if it is resolved

@Albedoww
Copy link
Author

@Albedoww please upgrade the latest version to see if it is resolved

thank you,that's work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants