Async Workflow/Node run Repository #16781

Closed
opened 2026-02-21 19:27:35 -05:00 by yindo · 4 comments
Owner

Originally created by @DavideDelbianco on GitHub (Sep 5, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.8.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Enable the new async repositories for workflow and node runs.
Deploy in HA configuration with at least two replicas of the worker.

✔️ Expected Behavior

Workers handles concurrency

Actual Behavior

Both workers will try to write the same run on DB and report the primary key as duplicate

Originally created by @DavideDelbianco on GitHub (Sep 5, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.8.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Enable the new async repositories for workflow and node runs. Deploy in HA configuration with at least two replicas of the worker. ### ✔️ Expected Behavior Workers handles concurrency ### ❌ Actual Behavior Both workers will try to write the same run on DB and report the primary key as duplicate
yindo added the 🐞 bug label 2026-02-21 19:27:35 -05:00
yindo closed this issue 2026-02-21 19:27:35 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Sep 5, 2025):

The duplicate primary key errors in async workflow/node run repositories with multiple worker replicas are caused by concurrent writes—multiple workers try to insert the same node execution at the same time, and the current engine lacks distributed locking or idempotency mechanisms to prevent this. This is not a UUIDv4 collision; it's a race condition in HA setups source.

A fix was merged after v1.8.1 that replaces UUID v4 with UUID v7 for better uniqueness and adds a retry mechanism to handle duplicate key errors gracefully. This change dramatically reduces the chance of conflicts and prevents nodes from getting stuck in the "Running" state source. However, this fix is not present in v1.8.1, and currently only applies to synchronous storage—async (Celery) tasks still lack robust retry/upsert logic for these conflicts source.

If you can't upgrade, you can manually recover stuck nodes by updating their status in the database to "failed" or "exception" to unblock the workflow. To reduce recurrence risk, add exception handling around the commit step, monitor for duplicate UUIDs, and implement upsert logic to safely handle unique constraint violations in your async task code source.

Keep an eye on future releases for improvements in async repository concurrency handling.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Sep 5, 2025): <!-- Answer --> The duplicate primary key errors in async workflow/node run repositories with multiple worker replicas are caused by concurrent writes—multiple workers try to insert the same node execution at the same time, and the current engine lacks distributed locking or idempotency mechanisms to prevent this. This is not a UUIDv4 collision; it's a race condition in HA setups [source](https://github.com/langgenius/dify/issues/25135). A fix was merged after v1.8.1 that replaces UUID v4 with UUID v7 for better uniqueness and adds a retry mechanism to handle duplicate key errors gracefully. This change dramatically reduces the chance of conflicts and prevents nodes from getting stuck in the "Running" state [source](https://github.com/langgenius/dify/pull/24643). However, this fix is not present in v1.8.1, and currently only applies to synchronous storage—async (Celery) tasks still lack robust retry/upsert logic for these conflicts [source](https://github.com/langgenius/dify/issues/25135#issuecomment-3252194399). If you can't upgrade, you can manually recover stuck nodes by updating their status in the database to "failed" or "exception" to unblock the workflow. To reduce recurrence risk, add exception handling around the commit step, monitor for duplicate UUIDs, and implement upsert logic to safely handle unique constraint violations in your async task code [source](https://github.com/langgenius/dify/issues/25135#issuecomment-3252194399). Keep an eye on future releases for improvements in async repository concurrency handling. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/41b8bdaf-a4f6-4ce0-a9f4-3105d580254d?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/25244)
Author
Owner

@crazywoola commented on GitHub (Sep 5, 2025):

I think it's not fully available in this version. Please checkout the second feature. https://github.com/langgenius/dify/releases

@crazywoola commented on GitHub (Sep 5, 2025): I think it's not fully available in this version. Please checkout the second feature. https://github.com/langgenius/dify/releases
Author
Owner

@DavideDelbianco commented on GitHub (Sep 9, 2025):

I am not talking about the queue based workflows, but the repository used to save the logs for workflow and node executions.
It was released with 1.8.0

@DavideDelbianco commented on GitHub (Sep 9, 2025): I am not talking about the queue based workflows, but the repository used to save the logs for workflow and node executions. It was released with 1.8.0
Author
Owner

@dosubot[bot] commented on GitHub (Oct 11, 2025):

Hi, @DavideDelbianco. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported duplicate primary key errors in async workflow/node run repositories with multiple worker replicas in version 1.8.1.
  • The root cause was a race condition due to lack of distributed locking or idempotency.
  • The issue was fixed after v1.8.1 by switching to UUIDv7 and adding retry logic.
  • Async tasks still lack fully robust concurrency handling, and manual recovery or exception handling is recommended until further improvements.
  • Users are advised to upgrade beyond version 1.8.1 to avoid this problem.

Next Steps:

  • Please confirm if this issue is still relevant with the latest version of Dify by commenting here.
  • Otherwise, I will automatically close this issue in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Oct 11, 2025): Hi, @DavideDelbianco. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported duplicate primary key errors in async workflow/node run repositories with multiple worker replicas in version 1.8.1. - The root cause was a race condition due to lack of distributed locking or idempotency. - The issue was fixed after v1.8.1 by switching to UUIDv7 and adding retry logic. - Async tasks still lack fully robust concurrency handling, and manual recovery or exception handling is recommended until further improvements. - Users are advised to upgrade beyond version 1.8.1 to avoid this problem. **Next Steps:** - Please confirm if this issue is still relevant with the latest version of Dify by commenting here. - Otherwise, I will automatically close this issue in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#16781