Timeout Issue with HTTP Requests or Custom Tool API Calls in Workflows

[opsvr202]

Self Checks

• [X] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [X] I have searched for existing issues search for existing issues, including closed ones.
• [X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [X] Please do not modify this template :) and fill in all the required fields.

Dify version

0.6.8

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. Add one or more HTTP request nodes or custom tool nodes in the workflow designer.
2. Save and publish the workflow.
3. Invoke the workflow using the API.
4. Observe if the API call times out after one minute and returns the aforementioned error message.

✔️ Expected Behavior

When invoking a workflow through the API, even if it contains HTTP request or custom tool nodes, it should complete as expected without timing out.

❌ Actual Behavior

When invoking a workflow through the API, if the workflow contains HTTP request or custom tool nodes, the interface times out after approximately one minute and returns an error message: "Node <node_name> run failed: Failed to invoke tool: timed out."

[dosubot[bot]]

To resolve the timeout issue with HTTP requests or custom tool API calls in workflows using Dify version 0.6.8, which is self-hosted on Docker, you can adjust the WORKER_TIMEOUT environment variable in the sandbox service configuration. This setting controls the timeout duration for the worker.

Here is the relevant section of the docker-compose.yaml file with the WORKER_TIMEOUT setting:

# The DifySandbox
sandbox:
  image: langgenius/dify-sandbox:0.2.0
  restart: always
  environment:
    # The DifySandbox configurations
    API_KEY: dify-sandbox
    GIN_MODE: 'release'
    WORKER_TIMEOUT: 60  # Adjust this value to a higher number to increase the timeout duration
    ENABLE_NETWORK: 'true'
    HTTP_PROXY: 'http://ssrf_proxy:3128'
    HTTPS_PROXY: 'http://ssrf_proxy:3128'
  volumes:
    - ./volumes/sandbox/dependencies:/dependencies
  networks:
    - ssrf_proxy_network

Increase the WORKER_TIMEOUT value to a higher number to allow more time for the HTTP requests or custom tool API calls to complete.

Additionally, you can configure the timeout settings directly in the workflow nodes for HTTP requests. Here is an example of how to set the connect, read, and write timeouts in the workflow node configuration:

const Timeout: FC<Props> = ({ readonly, payload, onChange }) => {
  const { t } = useTranslation()
  const { connect, read, write, max_connect_timeout, max_read_timeout, max_write_timeout } = payload ?? {}

  const [isFold, {
    toggle: toggleFold,
  }] = useBoolean(true)

  return (
    <>
      <div>
        <div
          onClick={toggleFold}
          className={cn('flex justify-between leading-[18px] text-[13px] font-semibold text-gray-700 uppercase cursor-pointer')}>
          <div>{t(`${i18nPrefix}.timeout.title`)}</div>
          <ChevronRight className='w-4 h-4 text-gray-500 transform transition-transform' style={{ transform: isFold ? 'rotate(0deg)' : 'rotate(90deg)' }} />
        </div>
        {!isFold && (
          <div className='mt-2 space-y-1'>
            <div className="space-y-3">
              <InputField
                title={t('workflow.nodes.http.timeout.connectLabel')!}
                description={t('workflow.nodes.http.timeout.connectPlaceholder')!}
                placeholder={t('workflow.nodes.http.timeout.connectPlaceholder')!}
                readOnly={readonly}
                value={connect}
                onChange={v => onChange?.({ ...payload, connect: v })}
                min={1}
                max={max_connect_timeout || 300}
              />
              <InputField
                title={t('workflow.nodes.http.timeout.readLabel')!}
                description={t('workflow.nodes.http.timeout.readPlaceholder')!}
                placeholder={t('workflow.nodes.http.timeout.readPlaceholder')!}
                readOnly={readonly}
                value={read}
                onChange={v => onChange?.({ ...payload, read: v })}
                min={1}
                max={max_read_timeout || 600}
              />
              <InputField
                title={t('workflow.nodes.http.timeout.writeLabel')!}
                description={t('workflow.nodes.http.timeout.writePlaceholder')!}
                placeholder={t('workflow.nodes.http.timeout.writePlaceholder')!}
                readOnly={readonly}
                value={write}
                onChange={v => onChange?.({ ...payload, write: v })}
                min={1}
                max={max_write_timeout || 600}
              />
            </div>
          </div>
        )}
      </div>
    </>
  )
}
export default React.memo(Timeout)

By adjusting both the WORKER_TIMEOUT in the Docker configuration and the specific timeout settings in the workflow nodes, you can effectively manage and resolve timeout issues in your Dify workflows.

Details

Sources

• Why is there a timeout on invididually run long running nodes inside Workflows
• The HTTP request workflow node supports setting timeout parameters.
• Customize the timeout for http request tools
• request timeout after 60s when use blocking mode with ollama
• Support customize API tool timeout
• docker/docker-compose.yaml
• web/app/components/workflow/nodes/http/components/timeout/index.tsx
• api/core/workflow/nodes/http_request/http_request_node.py

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.

[crazywoola]

Please upgrade to latest version to see if this is solved.

[opsvr202]

This issue was first discovered in v0.6.8. I upgraded to v0.6.9, but the bug still exists。