Feat: workflow/chatflow api support async

[luckylhb90]

Summary

It does not affect the current usage method.
Just by adding one parameter: is_async, the api interface can support asynchronous requests.
You just need to poll the new interface to obtain the result.
If possible, we may also send the result to kafka after it is available.

Tip

Resolve #13474

Screenshots

Before	After
none	chatflow:
none.	workflow:

Checklist

Important

Please review the checklist below before submitting your pull request.

• This change requires a documentation update, included: Dify Document
• I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods

[laipz8200]

I believe that this feature will make the Dify API highly susceptible to DDoS attacks, leading to resource exhaustion.

[luckylhb90]

I believe that this feature will make the Dify API highly susceptible to DDoS attacks, leading to resource exhaustion.

Then I think we should find ways to do a good job in DDos protection instead of DDos attacks caused by this interface. Is that right?

[laipz8200]

I believe that this feature will make the Dify API highly susceptible to DDoS attacks, leading to resource exhaustion.

Then I think we should find ways to do a good job in DDos protection instead of DDos attacks caused by this interface. Is that right?

Running workflows can be quite time-consuming. To enable asynchronous execution, it’s best to handle them using executors like Celery instead of running them directly within the web service.

Additionally, the current service API doesn’t prevent users from making asynchronous requests with simple await statements. This PR doesn’t actually introduce any new functionality and may instead make the interface more complex.

[gyf19]

[luckylhb90]

I believe that this feature will make the Dify API highly susceptible to DDoS attacks, leading to resource exhaustion.

Then I think we should find ways to do a good job in DDos protection instead of DDos attacks caused by this interface. Is that right?

Running workflows can be quite time-consuming. To enable asynchronous execution, it’s best to handle them using executors like Celery instead of running them directly within the web service.

Additionally, the current service API doesn’t prevent users from making asynchronous requests with simple await statements. This PR doesn’t actually introduce any new functionality and may instead make the interface more complex.

The main problem with asynchronous solution is that if the interface execution is too long, it is very easy for us to time out when we call it, and thus no result can be obtained. However, it is impossible for us to set the timeout time too long, as this would carry a higher risk. Therefore, asynchronous requests are still necessary.

[laipz8200]

That sounds reasonable. However, we still can't accept the current implementation.

Our team is already working on designing the asynchronous execution feature for Workflow. Before it releases, you can use this feature on your own branch.

[luckylhb90]

That sounds reasonable. However, we still can't accept the current implementation.

Our team is already working on designing the asynchronous execution feature for Workflow. Before it releases, you can use this feature on your own branch.

Ok. Thank you. Looking forward to this feature.

[pushiqiang]

That sounds reasonable. However, we still can't accept the current implementation.

Our team is already working on designing the asynchronous execution feature for Workflow. Before it releases, you can use this feature on your own branch.

@laipz8200 When can this feature be released ？