The workflow will report an error as long as it is connected to the end node.

Hisir0909 commented 4 months ago

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

Dify version

0.6.13

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

生成一周的菜单.txt The above is the DSL file of the workflow. Since it does not support yml, the suffix is changed to txt. As long as the end node is disconnected, it will be normal, but an error will occur if it is connected.

✔️ Expected Behavior

All processes except end are running normally, and end only outputs the previous content

❌ Actual Behavior

Once connected to end, it will be displayed "The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application."

dosubot[bot] commented 4 months ago

@Hisir0909 Hello there! 👋 I'm here to help you with bug fixes, answer your questions, and guide you on becoming a contributor. I'm looking forward to assisting you with your issue.

The issue you're encountering with the end node in Dify version 0.6.13 could be related to specific configurations in the DSL file or the end node's setup. Here are a few potential causes and solutions:

Outputs Configuration: Ensure that the end node's outputs configuration is correctly set. The default configuration sets outputs to an empty array, which is expected behavior for an end node. However, if your workflow requires the end node to produce outputs, this might need adjustment.
```
defaultValue: {
    outputs: [],
},
```
Available Previous Nodes: The getAvailablePrevNodes function filters available previous nodes based on the mode (chat or completion). Ensure that the mode is correctly set and that the filtering logic covers all necessary node types.
```
getAvailablePrevNodes(isChatMode: boolean) {
    const nodes = isChatMode
        ? ALL_CHAT_AVAILABLE_BLOCKS
        : ALL_COMPLETION_AVAILABLE_BLOCKS.filter(type => type !== BlockEnum.End)
    return nodes
},
```

Validation Logic: The checkValid function currently only checks if the payload.type exists. If there are other required fields or conditions that need to be validated, this simplistic validation could cause issues.

checkValid(payload: EndNodeType) {
    let isValid = true
    let errorMessages = ''
    if (payload.type) {
        isValid = true
        errorMessages = ''
    }
    return {
        isValid,
        errorMessage: errorMessages,
    }
},

Review these configurations to ensure they align with the expected behavior and requirements of the end node in your workflow. If the issue persists, it might be helpful to check the specific error logs generated by the Dify application for more detailed information on the error ^[1].

Additionally, ensure that your Docker setup is correctly configured for logging and error tracking. You can access the logs using the following Docker command:

docker logs <container_id>

Replace <container_id> with the actual container ID of your Dify service ^[2].

To continue talking to Dosu, mention @dosu.

crazywoola commented 4 months ago

Hello can you try using Cloud SaaS version to see if it works. Maybe it's related to the configuration of UnstructureIO

Hisir0909 commented 4 months ago

@crazywoola In fact, this strange bug originally came from the cloud version, but I found that after exporting it and running it in the docker version, the same error occurred. 😆

crazywoola commented 4 months ago

I guess the template is wrong somehow.

langgenius / dify