Skip to content

Conversation

@CalvinKirs
Copy link
Member

What problem does this PR solve?

When querying the execution records of tasks, the current system has two sources that may describe task status:

Task status in the scheduling module: Represents the processing status of tasks within the scheduling system.
Task status in LoadManager: Specifically refers to the status of Insert-type tasks, containing more detailed execution information.

When the data in the LoadManager is deleted or expires, the completion status will revert to the task status from the scheduling system, which could cause confusion. Therefore, consistency needs to be maintained.

Since these two sources may have inconsistencies in their status information, they can easily cause confusion for users and developers.

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

CalvinKirs and others added 3 commits December 12, 2024 14:56
…on Records

When querying the execution records of tasks, the current system has two sources that may describe task status:

Task status in the scheduling module: Represents the processing status of tasks within the scheduling system.
Task status in LoadManager: Specifically refers to the status of Insert-type tasks, containing more detailed execution information.

When the data in the LoadManager is deleted or expires, the completion status will revert to the task status from the scheduling system, which could cause confusion. Therefore, consistency needs to be maintained.

Since these two sources may have inconsistencies in their status information, they can easily cause confusion for users and developers.
@CalvinKirs
Copy link
Member Author

run buildall

Copy link
Member

@zy-kkk zy-kkk left a comment

Choose a reason for hiding this comment

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

LGTM

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Dec 13, 2024
@github-actions
Copy link
Contributor

PR approved by at least one committer and no changes requested.

@github-actions
Copy link
Contributor

PR approved by anyone and no changes requested.

@CalvinKirs CalvinKirs merged commit 41e554d into apache:master Dec 13, 2024
36 of 37 checks passed
@CalvinKirs CalvinKirs deleted the master-fix-job-status branch December 13, 2024 08:57
github-actions bot pushed a commit that referenced this pull request Dec 13, 2024
…on Records (#45342)

### What problem does this PR solve?


When querying the execution records of tasks, the current system has two
sources that may describe task status:

Task status in the scheduling module: Represents the processing status
of tasks within the scheduling system.
Task status in LoadManager: Specifically refers to the status of
Insert-type tasks, containing more detailed execution information.

When the data in the LoadManager is deleted or expires, the completion
status will revert to the task status from the scheduling system, which
could cause confusion. Therefore, consistency needs to be maintained.

Since these two sources may have inconsistencies in their status
information, they can easily cause confusion for users and developers.
CalvinKirs added a commit that referenced this pull request Dec 16, 2024
…uery Execution Records #45342 (#45405)

Cherry-picked from #45342

Co-authored-by: Calvin Kirs <guoqiang@selectdb.com>
CalvinKirs added a commit to CalvinKirs/incubator-doris that referenced this pull request Dec 16, 2024
CalvinKirs added a commit that referenced this pull request Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. dev/2.1.8-merged dev/3.0.4-merged reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants