Skip to content

Conversation

@shaohuzhang1
Copy link
Contributor

fix: Error in total time consumption statistics for executing records

@f2c-ci-robot
Copy link

f2c-ci-robot bot commented Dec 8, 2025

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@f2c-ci-robot
Copy link

f2c-ci-robot bot commented Dec 8, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@shaohuzhang1 shaohuzhang1 merged commit ff26835 into v2 Dec 8, 2025
3 of 5 checks passed
@shaohuzhang1 shaohuzhang1 deleted the pr@v2@fix_knowledge_workflow branch December 8, 2025 07:48
'start_time') is not None else 0)


class NodeResult:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The provided code has several irregularities and potential optimizations:

  1. Inconsistent Use of for Loop: In the constructor (__init__) and handler, there are different use cases for loops (if ... else if vs. list comprehension). This can be inconsistent and lead to bugs.

  2. Potential Null Value: The line at the end of the handler method uses workflow.context.get('start_time'), which could potentially return None. Using 0 when it's missing doesn't align with common practice (e.g., handling null values).

  3. Useless List Comprehension: The list comprehension [True for key, value in workflow.get_runtime_details().items() if value.get('status') == 500] creates a list without using its elements. It would be more efficient to just calculate the error flag directly without storing all individual True/False results.

  4. Redundant Time Calculation: Calculating time.time() - workflow.context.get('start_time') twice within an assignment statement is redundant. Only calculate it once if needed multiple times or store in variable first.

Optimized version:

class KnowledgeActionModel(models.Model):
    state = models.CharField(max_length=16)
    
    # Ensure this function exists or replace it with equivalent logic if necessary
    def update_state(self, workflow):
        err = any(value['status'] == 500 for value in workflow.get_runtime_details())
        
        # Calculate only once
        run_time_seconds = time.time() - (
            workflow.context.get('start_time', 0)
        )
        
        self.state = State.FAILURE if err else State.SUCCESS
        self.run_time = round(run_time_seconds, 2)  

Additional notes:

  • Assuming Django ORM usage (models.Model), ensure all referenced classes (KnowledgeAction, State). If these are custom classes elsewhere, adjust accordingly.
  • Error handling should typically occur before performing database operations, especially sensitive ones like updating state.
  • Consider refactoring to separate concerns better; e.g., move time calculation into utility functions or methods outside class definitions.

self.context['start_time'] = time.time()
executor.submit(self._run)

def _run(self):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The provided code looks mostly clean and follows Python best practices. However, there are a few areas that could be improved:

  1. Import Statement: The traceback module is not used anywhere in the code snippet you've shared. If this import was intended to handle exceptions differently, consider removing it unless necessary.

  2. Concurrency Initialization: While using ThreadPoolExecutor is good practice for parallel processing, ensure that all tasks are correctly submitted through executor.submit(). There might be some context handling required before submitting tasks.

  3. Context Management: Accessing variables like self.context['start_time'] should be done within methods where such variables are defined or updated. It could lead to errors if _init_context() returns an empty dictionary.

  4. Task Submission Handling: Currently, _run() is only being called once by a single thread when _run() itself submits further tasks to executor, but since each task calls back into _run(), care should be taken to prevent infinite recursion loops.

Here's a revised version of the method assuming proper usage conventions:

def run(self):
    # Initialize execution time
    self.context['start_time'] = time.time()

    # Submit initial task
    future = executor.submit(self._run)

    try:
        # Wait until all futures complete
        future.result(timeout=None)
    except Exception as e:
        print(f"An error occurred: {e}")

This change ensures that the initialization step and subsequent submission of tasks work together seamlessly without any logical inconsistencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants