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

Using a parallel connection to connect two code executors after LLM can cause problems #8453

Closed
5 tasks done
massif-01 opened this issue Sep 14, 2024 · 2 comments
Closed
5 tasks done
Labels
🐞 bug Something isn't working

Comments

@massif-01
Copy link
Contributor

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).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.8.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When I use LLM to write outline, output json, and use two code executors in parallel after LLM to separately extract different contents in json, Dify reports error as follows: Node beginning extraction related parallel not found or incorrectly connected to multiple parallel branches. After testing, there is no problem with the code, because Dify will not report errors when not using parallel mode. And in 0.8.1, such an orchestration design does not report an error and can run normally.
截屏2024-09-15 02 59 27
截屏2024-09-15 02 59 38

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Copy link

dosubot bot commented Sep 14, 2024

Hello @massif-01! I'm here to assist you with bug reports, answer questions, and help you become a contributor. Let me know how I can help while you wait for a human maintainer.

I found a similar unsolved discussion regarding issues with parallel execution in Dify version 0.8.0. You can check it out here [1].

To resolve the error in Dify 0.8.2 when using parallel code executors after LLM to extract different contents from JSON, ensure that the JSON structure and types match the expected schema defined in the _transform_result method. The error might be due to type mismatches or depth/length constraints.

Here are some key constraints and checks performed in the _transform_result method:

  1. Depth Limit: Ensure the JSON depth does not exceed dify_config.CODE_MAX_DEPTH.
  2. String Length: Ensure strings do not exceed dify_config.CODE_MAX_STRING_LENGTH.
  3. Number Range: Ensure numbers are within the range defined by dify_config.CODE_MAX_NUMBER and dify_config.CODE_MIN_NUMBER.
  4. Precision: Ensure the precision of floating-point numbers does not exceed dify_config.CODE_MAX_PRECISION.
  5. Array Lengths: Ensure arrays do not exceed the maximum lengths defined by:
    • dify_config.CODE_MAX_NUMBER_ARRAY_LENGTH for arrays of numbers.
    • dify_config.CODE_MAX_STRING_ARRAY_LENGTH for arrays of strings.
    • dify_config.CODE_MAX_OBJECT_ARRAY_LENGTH for arrays of objects.
  6. Type Validation: Ensure that the types of the JSON elements match the expected types (e.g., strings, numbers, objects).

Here is an example of how you might adjust your JSON data to fit these constraints:

{
  "example_string": "This is a valid string",
  "example_number": 123,
  "example_float": 123.45,
  "example_array_numbers": [1, 2, 3],
  "example_array_strings": ["one", "two", "three"],
  "example_object": {
    "nested_string": "Nested string",
    "nested_number": 456
  },
  "example_array_objects": [
    {"nested_string": "Object 1"},
    {"nested_string": "Object 2"}
  ]
}

Ensure that your JSON data adheres to these constraints and types to avoid errors during the transformation process [2].

Additionally, there are specific configuration settings or parameters that need to be adjusted for parallel execution in Dify:

  1. SERVER_WORKER_AMOUNT: Sets the number of API server workers (gevent workers). The recommended formula is number of CPU cores x 2 + 1.

    SERVER_WORKER_AMOUNT: <number_of_workers>
  2. CELERY_WORKER_AMOUNT: Sets the number of Celery workers. The default is 1, but it can be adjusted as needed.

    CELERY_WORKER_AMOUNT: <number_of_workers>
  3. SERVER_WORKER_CLASS and CELERY_WORKER_CLASS: Define the worker class. The default is gevent, but it can be changed to sync or solo for Windows.

    SERVER_WORKER_CLASS: gevent
    CELERY_WORKER_CLASS: gevent
  4. GUNICORN_TIMEOUT: Sets the request handling timeout. The default is 200, but a recommended value is 360 to support longer SSE (Server-Sent Events) connection times.

    GUNICORN_TIMEOUT: 360

These settings help in configuring the parallel execution environment in Dify [3][4].

To continue talking to Dosu, mention @dosu.

@dosubot dosubot bot added the 🐞 bug Something isn't working label Sep 14, 2024
@crazywoola
Copy link
Member

We fixed in latest branch. See Cloud.

Link #8378 #8440

QQ_1726363133641

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