Conversation
…pache#67924) A cloud warm-up job registers its destination compute group before initializing tablet batches. If initialization throws, the outer `run()` handler only logs the exception: the job stays `PENDING` and keeps the destination registration. Other ONCE/PERIODIC jobs targeting that group cannot start. A later successful retry can recover the original job, but repeated initialization failures can block the group indefinitely because the warm-up timeout only applies to `RUNNING` jobs. Catch initialization failures before transitioning to `RUNNING` and reuse `cancel(..., false)` to persist the error and release the destination registration. ONCE jobs become `CANCELLED`; PERIODIC jobs remain `PENDING` and retry at their existing interval. Initialization has not submitted work to BEs, so this path does not send cleanup RPCs. Successful initialization retains the destination registration as before. Release the destination compute group when cloud warm-up initialization fails, allowing subsequent warm-up jobs to proceed. Report the initialization error and preserve periodic retry scheduling. (cherry picked from commit f0affa9)
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
bobhan1
marked this pull request as ready for review
September 17, 2026 03:45
Contributor
Author
|
run buildall |
Contributor
FE UT Coverage ReportIncrement line coverage |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
Backport #67924 to branch-4.1 (source commit f0affa9).
When tablet-batch initialization fails, release the warm-up destination registration and persist the error. ONCE jobs become CANCELLED; PERIODIC jobs remain PENDING and retry at their existing interval. No BE cleanup RPC is sent before a BE job has started.
Conflict resolution
Production code applied unchanged. The only conflict was in CloudWarmUpJobTest: master migrated this class from JUnit 4 to JUnit 5 in #67396 (050442d), while branch-4.1 retains JUnit 4. Keep the target framework and express the two EnumSource tests as four independent JUnit 4 tests, preserving ONCE/PERIODIC failure and success coverage.
Validation
./run-fe-ut.sh --run 'org.apache.doris.cloud.CloudWarmUpJobTest,org.apache.doris.cloud.CacheHotspotManagerSchedulerTest,org.apache.doris.cloud.cache.CacheHotspotManagerTest': 30 tests, zero failures/errors/skips; BUILD SUCCESS.git diff --check upstream/branch-4.1...HEAD.Release note
Release the destination compute group when cloud warm-up initialization fails, allowing subsequent warm-up jobs to proceed while preserving periodic retry scheduling.