How to Adjust Maximum Retry Attempts and Retry Interval for LLM node？

[yanpx169]

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

dify version:1.9.1 ，Deployed with Docker

Due to rate limiting issues with the LLM I am currently using, I need to modify the maximum number of retry attempts and the maximum retry interval. However, I have checked the .env and docker-compose.yaml files and did not find any related configurations. Could you please advise how I can adjust the following values? I would like to set them as follows:

• The maximum number of retries is 20
• The maximum retry interval is 10000 ms

[dosubot[bot]]

You can't adjust the maximum retry attempts or retry interval for LLM nodes using .env or docker-compose.yaml—these settings aren't exposed as environment variables or global configs. The retry logic is configured per node in the workflow via a retry_config object. The backend supports any values, but the UI enforces limits: max retries is capped at 10 and retry interval at 5000 ms in the input fields source.

To set higher values (like 20 retries and 10,000 ms interval), you need to bypass the UI. You can do this by manually editing the workflow JSON or using the API to set the retry_config for your LLM node:

"retry_config": {
  "retry_enabled": true,
  "max_retries": 20,
  "retry_interval": 10000
}

Once set, the backend will honor these values even though the UI won't let you input them directly. There is no system-wide or global retry config—it's always per-node in the workflow.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[yanpx169]

Thank you very much, I'm not familiar with how to use these two interfaces. Could you please provide a detailed example of how to use them?

[dosubot[bot]]

Here’s a step-by-step example of how to update your existing Dify app’s workflow using the two API endpoints:

1. Prepare your modified workflow JSON

Export your workflow DSL, make your changes (e.g., set "max_retries": 20 and "retry_interval": 10000 in the relevant node’s retry_config), and save the updated JSON.

2. Authenticate

These endpoints require you to be logged in with edit permissions. If you use the web UI, your browser session is authenticated. For API calls, you typically need a session cookie or a bearer token (check your Dify deployment for how to obtain this—often via login or API key).

3. Sync the draft workflow

Send a POST request to /apps/{app_id}/workflows/draft with your updated workflow. Replace {app_id} with your app’s ID (you can find this in the app’s URL or via the UI/API).

Example using curl (replace placeholders as needed):

curl -X POST "http://<your-dify-host>/console/api/apps/<app_id>/workflows/draft" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your_token_or_cookie>" \
  -d '{
    "graph": { ... },  // your updated workflow graph
    "features": { ... },  // your features config
    "environment_variables": [],
    "conversation_variables": []
  }'

• graph and features are required and should match your modified DSL.
• environment_variables and conversation_variables are lists (use empty lists if not needed).
• The response will include a result, new hash, and updated_at timestamp.
  API details

4. Publish the draft workflow

Once the draft is synced, publish it to make it live:

curl -X POST "http://<your-dify-host>/console/api/apps/<app_id>/workflows/publish" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your_token_or_cookie>" \
  -d '{}'

You can optionally include marked_name and marked_comment in the payload (max 20 and 100 characters, respectively).
The response will confirm success and show the created_at timestamp.

Notes:

• Both endpoints require authentication and edit permissions.
• If you get a 403 or 401 error, check your login/session or token.
• If you don’t know your app_id, you can find it in the app’s URL or via the Dify UI/API.

Let me know if you want a Python example or have questions about authentication!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[yanpx169]

Thank you very much for your patient guidance. I followed the API method you provided and attempted the following: after sending the "Publish the draft workflow" request, I refreshed the browser and checked the LLM node's "max retries" value via the UI—it still shows 4 and did not change as expected. I also tried setting it to other values (e.g., 20), but the issue persisted. Could you please advise how to resolve this problem?

[dosubot[bot]]

The error "Workflow graph might have been modified, please refresh and resubmit." means your draft workflow update failed due to a version/hash conflict—so your changes (like retry settings) were not saved. Publishing after a failed draft update just republishes the old workflow, which is why the UI still shows the previous retry value.

To fix this:

1. Fetch the latest draft workflow from the API (GET /apps/{app_id}/workflows/draft) and note the hash value.
2. Apply your changes (set "max_retries": 20, "retry_interval": 10000 in the LLM node's retry_config) to this latest draft.
3. Submit the updated draft using POST /apps/{app_id}/workflows/draft, including the up-to-date hash in your payload.
4. Publish the draft with POST /apps/{app_id}/workflows/publish.

This ensures your update is accepted and the new settings are live.
The backend will honor values above the UI limits (e.g., max_retries > 10, retry_interval > 5000) if set via API or JSON—there are no backend constraints on these fields source. However, the UI may not display values above its own limits, even if they are active in the backend.

If you want to confirm the backend value, you can fetch the published workflow via API and inspect the node config in the returned JSON.

Let me know if you need example API calls for these steps!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[yanpx169]

This issue has been resolved following your guidance—thank you very much for your help!