langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #24643] Fix: Resolve workflow_node_execution primary key conflicts with UUID v7 #30731

New Issue
Closed
opened 2026-02-21 20:48:07 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:48:07 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/24643

State: closed
Merged: Yes

Summary

  • Fixes #23174: workflow_node_execution stuck in "Running" state due to duplicate key conflicts
  • Replaces UUID v4 with UUID v7 for better uniqueness guarantees in high-concurrency scenarios
  • Adds robust conflict handling with retry mechanism

Changes

  1. Implemented UUID v7 generator (api/core/workflow/utils/uuid_utils.py)

    • Time-ordered UUIDs provide better uniqueness in concurrent scenarios
    • Improves database index performance with monotonic ordering
    • Compatible with Python 3.11

  2. Updated workflow node execution ID generation (api/core/workflow/workflow_cycle_manager.py)

    • Replaced uuid4() with uuid7_str() for node execution IDs

  3. Enhanced repository save method (api/core/repositories/sqlalchemy_workflow_node_execution_repository.py)

    • Added duplicate key conflict detection and retry logic
    • Generates new UUID v7 on conflict (up to 3 retries)
    • Properly handles both insert and update scenarios

  4. Added comprehensive tests

    • UUID v7 generation and validation tests
    • Conflict handling and retry mechanism tests
    • Concurrency safety tests

Test Plan

  • Unit tests for UUID v7 generation pass
  • Conflict handling tests pass
  • Code passes linting and formatting checks
  • All existing tests continue to pass

Impact

This fix prevents workflow nodes from getting stuck in "Running" state when duplicate key conflicts occur, especially at the start node where the issue was most commonly observed.

The probability of conflicts is now extremely low due to:

  • UUID v7's timestamp-based uniqueness
  • Cryptographically secure random bits
  • Retry mechanism as a safety net
**Original Pull Request:** https://github.com/langgenius/dify/pull/24643 **State:** closed **Merged:** Yes --- ## Summary - Fixes #23174: workflow_node_execution stuck in "Running" state due to duplicate key conflicts - Replaces UUID v4 with UUID v7 for better uniqueness guarantees in high-concurrency scenarios - Adds robust conflict handling with retry mechanism ## Changes 1. **Implemented UUID v7 generator** (`api/core/workflow/utils/uuid_utils.py`) - Time-ordered UUIDs provide better uniqueness in concurrent scenarios - Improves database index performance with monotonic ordering - Compatible with Python 3.11 2. **Updated workflow node execution ID generation** (`api/core/workflow/workflow_cycle_manager.py`) - Replaced `uuid4()` with `uuid7_str()` for node execution IDs 3. **Enhanced repository save method** (`api/core/repositories/sqlalchemy_workflow_node_execution_repository.py`) - Added duplicate key conflict detection and retry logic - Generates new UUID v7 on conflict (up to 3 retries) - Properly handles both insert and update scenarios 4. **Added comprehensive tests** - UUID v7 generation and validation tests - Conflict handling and retry mechanism tests - Concurrency safety tests ## Test Plan - [x] Unit tests for UUID v7 generation pass - [x] Conflict handling tests pass - [x] Code passes linting and formatting checks - [x] All existing tests continue to pass ## Impact This fix prevents workflow nodes from getting stuck in "Running" state when duplicate key conflicts occur, especially at the start node where the issue was most commonly observed. The probability of conflicts is now extremely low due to: - UUID v7's timestamp-based uniqueness - Cryptographically secure random bits - Retry mechanism as a safety net
yindo added the pull-request label 2026-02-21 20:48:07 -05:00
yindo closed this issue 2026-02-21 20:48:07 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#30731
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?