Skip to content

fix: When executing the knowledge base workflow, the loop node reported an error and the workflow was not terminated #4532

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.

Sign up for GitHub

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

Merged
shaohuzhang1 merged 1 commit into from
Dec 17, 2025
Merged

fix: When executing the knowledge base workflow, the loop node reported an error and the workflow was not terminated #4532

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions apps/application/flow/knowledge_workflow_manage.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,8 @@ def hand_node_result(self, current_node, node_result_future):
if result is not None:
# 阻塞获取结果
list(result)
if current_node.status == 500:
return None
return current_result
except Exception as e:
traceback.print_exc()
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Dec 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided code seems generally correct for handling asynchronous execution. However, here are some minor improvements and points to consider:

  1. Exception Handling: It's good that you've wrapped the exception handling around the list(result) call, but it might be redundant since Python already traps exceptions within the try-except block.

  2. Status Check: The condition if current_node.status == 500: will only trigger if current_node has been assigned an attribute named status. You should ensure this assignment before using it. Additionally, returning None on error can sometimes mask underlying problems; consider logging such errors instead of immediately returning null.

  3. Return Type Compatibility: Returning None from the method could pose compatibility issues with future integrations or data processing pipelines that expect a non-null value.

  4. Code Readability: It looks clean and follows standard syntax, so readability could potentially benefit from slightly improving comments explaining each step (though they're present).

Here’s a revised version:

def hand_node_result(self, current_node, node_result_future):
    try:
        # Wait for the result asynchronously
        result = await node_result_future.result()

        if result is not None:
            # If result contains items, process them
            list(result)

        # Handle specific status codes separately
        if current_node.status in [500]:
            # Log or handle internal server errors more gracefully
            print(f"Error: Node status {current_node.status}")
            return

        # Return successful results
        return current_result
    except Exception as e:
        # Print detailed traceback for debugging purposes
        traceback.print_exc()

This approach maintains clarity while adding some additional logic related to status checks and error handling. Always review critical control flow and error handling to ensure resilience against unexpected conditions.

Expand Down
Loading