[fix](regression) Wait for completed profiles in RF pruning tests#64392
Merged
BiteTheDDDDt merged 8 commits intoJun 16, 2026
Merged
Conversation
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Runtime-filter partition-pruning regression tests read FE query profiles immediately after query completion. Query completion does not guarantee that asynchronous BE profile reports have been merged, so the tests can see RF pruning counters before their final values and fail with zero partition counters. This change exposes a profile completion state in the query profile REST list based on ExecutionProfile.isCompleted(), persists the terminal state before profile spill, and updates the RF pruning profile pollers to wait for COMPLETE before reading counter values.
### Release note
None
### Check List (For Author)
- Test: Manual test
- Ran git diff --check.
- Tried ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList, but fe-core compilation failed before running the test because generated parser/proto classes are inconsistent with Java sources.
- Behavior changed: Yes. /rest/v1/query_profile rows include Profile Completion State.
- Does this need documentation: No
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
/review |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR stabilizes runtime-filter partition-pruning regression tests by ensuring they only read query profile counters after the profile has fully finished collecting BE reports. It also exposes and persists a new “Profile Completion State” field in the FE query-profile REST listing to support this polling behavior.
Changes:
- Add “Profile Completion State” to
/rest/v1/query_profilerows and compute it fromProfile/ExecutionProfile.isCompleted(). - Persist a terminal completion state into the stored profile metadata before spilling profiles to disk.
- Update RF pruning regression suites to poll until the profile state is
COMPLETEbefore reading counter values.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| regression-test/suites/query_p0/runtime_filter/rf_partition_pruning.groovy | Waits for profile completion state COMPLETE before fetching profile text/counters. |
| regression-test/suites/query_p0/runtime_filter/rf_partition_pruning_type_matrix.groovy | Same completion-state polling to avoid reading partial counters. |
| fe/fe-core/src/test/java/org/apache/doris/common/profile/ProfileManagerTest.java | Adds UT coverage asserting completion-state values in query list output. |
| fe/fe-core/src/main/java/org/apache/doris/httpv2/controller/QueryProfileController.java | Appends the new completion-state column to /rest/v1/query_profile output. |
| fe/fe-core/src/main/java/org/apache/doris/common/profile/SummaryProfile.java | Introduces completion-state constants and a setter for storage metadata. |
| fe/fe-core/src/main/java/org/apache/doris/common/profile/ProfileManager.java | Supports dynamically providing completion state when building query list rows. |
| fe/fe-core/src/main/java/org/apache/doris/common/profile/Profile.java | Implements completion-state computation and persists terminal state on spill. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Review opinion: no blocking issues found.
Critical checkpoint conclusions:
- Goal/test proof: The PR addresses the stated RF partition-pruning profile race by exposing a query-list completion state and making the affected regression pollers wait for COMPLETE before reading counters. A FE unit test covers RUNNING, COLLECTING, and COMPLETE list states; the two target regression suites are updated.
- Scope/focus: The implementation is small and focused on profile list metadata plus the two flaky pollers.
- Concurrency/lifecycle: The change derives state from existing Profile/ExecutionProfile lifecycle markers and does not add locks or heavy work under new locks. I checked the Coordinator/profile-IO interaction and did not find a new race beyond existing profile-manager synchronization patterns.
- Config changes: None.
- Compatibility/storage: The v1 /rest/v1/query_profile response gains one extra row-map key. Stored profiles persist the terminal state in SummaryProfile before execution profiles are released; older stored profiles fall back to UNKNOWN. No EditLog or query-data format compatibility concern found.
- Parallel paths: The changed v1 path is the one used by ProfileAction in these regression tests; v2 manager/query and SHOW profile schemas are not changed.
- Conditional checks: The new state distinctions are straightforward and tied to query-finished plus ExecutionProfile.isCompleted().
- Test coverage/results: No .out file is required for these changes. I ran git diff --check only; I did not run FE UT or regression suites in this review environment.
- Observability: No additional logs or metrics appear necessary for this narrow metadata exposure.
- Transactions/data writes/FE-BE variables: No transaction path, user data write path, or FE-BE variable propagation is involved.
- Performance: The query list now checks completion state per listed profile; this is bounded by existing profile-list size and acceptable for this endpoint.
- Other issues: None found.
Existing inline review context: there were no existing inline review threads to de-duplicate against. User focus: no additional user-provided review focus was present.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Contributor
Author
|
/review |
Contributor
Author
|
run buildall |
Contributor
There was a problem hiding this comment.
Requesting changes.
Critical checkpoint conclusions:
- Goal/test: The PR aims to wait RF pruning tests until async BE profile reports are fully merged. The direction is reasonable, and it adds FE/regression coverage, but the current head cannot be accepted because the FE source has a syntax error.
- User focus: No additional user-provided focus points were present.
- Scope: The change is mostly focused on FE profile state plus the two RF pruning pollers.
- Concurrency: This area is explicitly concurrent: servlet/profile-list readers, profile-manager IO/daemon threads, coordinator/load threads, and the profile-write-pool all touch profile state. The existing ArrayList concern was addressed, but the new completion check still reaches an unlocked RuntimeProfile.childList read while report merging mutates it.
- Lifecycle/persistence: Persisting the terminal state in SummaryProfile before profile spill is the right lifecycle point; older stored profiles fall back to UNKNOWN. No new static lifecycle issue found.
- Config/compatibility: No new config, FE-BE thrift field, storage format, or rolling-upgrade-sensitive protocol change found. The REST list adds an intended new column.
- Parallel paths: /rest/v1/query_profile is updated for the new state. SHOW query/load profile paths do not expose this new column, which seems acceptable for the stated regression-test goal.
- Data correctness/transactions: No query data visibility, transaction, version, or delete-bitmap behavior is changed.
- Testing: I attempted
./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList, but this runner failed before Java compilation becausethirdparty/installed/bin/protocis missing.git diff --checkpassed for the changed files. - Observability/performance: No additional metric/log requirement found; the on-demand state scan is bounded by profile/execution-profile counts, but it needs the concurrency fix noted inline.
…le.java Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile completion state queries inspect execution profiles while backend profile reports may still append fragment child profiles on the profile write pool. Checking the child list without holding RuntimeProfile's child lock can race with addChild. Move the completion check into RuntimeProfile so the child list size and done/cancel flags are read under the existing read lock. ### Release note None ### Check List (For Author) - Test: Manual test - git diff --check - Attempted ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList, but FE compilation failed before test execution due existing generated parser/proto mismatches unrelated to this change. - Behavior changed: No - Does this need documentation: No
Contributor
Author
|
/review |
Contributor
Author
|
run buildall |
Contributor
There was a problem hiding this comment.
Review result: request changes. I found one new correctness issue in the completion-state predicate: it can report COMPLETE before every backend has reported, so the RF pruning tests can still read incomplete counters.
Critical checkpoints:
- Goal/test: The goal is to wait for fully merged asynchronous BE profiles before reading RF counters. The current code does not fully accomplish that because completion is based on child profile node count, not distinct backend reports. The new FE unit test covers RUNNING/COLLECTING/COMPLETE states, but it does not cover a multi-BE fragment where one BE contributes multiple child profiles.
- Scope/focus: The change is otherwise focused on the REST profile list, profile persistence, and two regression pollers.
- Concurrency: The latest head moves child-list reads under RuntimeProfile.childLock, addressing the already-known child-list race. I did not add duplicate comments for the existing review threads.
- Lifecycle/persistence: Persisting the terminal state before spill and returning UNKNOWN for older stored profiles looks reasonable.
- Config/compatibility: No new config or incompatible wire/storage format change found; the REST response adds a column.
- Parallel paths: SHOW/manager profile paths are not updated with the new column, but the PR's stated consumer is /rest/v1/query_profile, so I did not treat that as blocking.
- Tests: Missing coverage for the multi-backend/multiple-child-profile case described inline.
- Observability/performance/transactions: No additional issue found.
- User focus: No additional user-provided review focus.
Contributor
TPC-H: Total hot run time: 29493 ms |
Contributor
TPC-DS: Total hot run time: 169641 ms |
Contributor
FE Regression Coverage ReportIncrement line coverage |
added 2 commits
June 13, 2026 18:21
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile text generated before storage did not refresh the newly added profile completion state in the summary profile. When the same profile was written to storage, the storage path persisted the completion state and subsequent reads printed an extra summary line, making ProfilePersistentTest compare different strings. Refresh the display completion state before pretty-printing the summary, while keeping the existing storage-specific state used when persisting incomplete finished profiles. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfilePersistentTest#testGetOnStorageProfile - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList - git diff --check - Behavior changed: No - Does this need documentation: No
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile completion state checked fragment RuntimeProfile child-node count against the expected backend count. A single backend report can add multiple child profile nodes, including a fragment-level profile and pipeline profiles, so the state could become COMPLETE before every backend report had been merged. Track the distinct backend addresses whose done reports have been merged for each fragment and use that count for completion. Add unit coverage for a two-backend fragment where the first backend contributes multiple profile nodes. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#profileCompletionStateWaitsForDistinctBackendReports - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList - git diff --check - Behavior changed: No - Does this need documentation: No
Contributor
Author
|
run buildall |
Contributor
Author
|
/review |
Contributor
There was a problem hiding this comment.
No additional blocking findings from this pass. I reviewed the current head against the existing inline threads and did not re-raise the already-known compile/concurrency/completion-count concerns; the latest code addresses those by using index-based execution profile traversal and distinct done-backend tracking.
Checkpoint conclusions:
- Goal and tests: The PR goal is to let RF pruning regression pollers wait until async BE profile reports are merged. The implementation exposes a completion state and adds focused FE unit coverage plus regression poller updates. I could not rerun FE UT in this runner because thirdparty/installed/bin/protoc is missing, per FE build prerequisites.
- Scope: The change is focused on profile completion state and the two RF pruning pollers.
- Concurrency: The relevant concurrency is BE report merging on profile-write-pool versus REST/profile-list reads. The new done-backend set is protected by multiBeProfileLock and completion no longer reads RuntimeProfile childList directly. ProfileManager read/write locking still protects storage release versus list reads.
- Lifecycle/storage: Stored profiles persist COMPLETE or INCOMPLETE before memory release; old stored profiles without the new field fall back to UNKNOWN.
- Compatibility/API: /rest/v1/query_profile gains one user-visible column. Existing row construction is dynamic, and the changed regression helper reads it by name.
- Parallel paths: Display and storage paths both refresh the state; realtime profile fetch remains separate and does not mark completion until BE done reports are merged.
- Tests/results: New FE unit tests cover RUNNING/COLLECTING/COMPLETE and the distinct-backend case. Regression helpers now wait for COMPLETE and counters. No generated .out files are involved.
- Observability/performance: No new heavy logging or hot-path overhead found; the extra profile-list work is bounded by current profile rows and existing execution profile metadata.
User focus: .code-review.Ogvn8v/review_focus.txt contained no additional focus points, so no extra focus-specific issue was found.
Contributor
TPC-H: Total hot run time: 28824 ms |
Contributor
TPC-DS: Total hot run time: 168111 ms |
Contributor
FE Regression Coverage ReportIncrement line coverage |
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: RF partition-pruning regression tests waited for Profile Completion State to become COMPLETE before reading the profile detail. Query completion and final profile merging are asynchronous, so the profile row can be visible while the completion state is still COLLECTING. In that window the poller returned an empty profile and failed with "Profile not found" even though the profile detail may already be readable. This change keeps the latest non-empty profile detail while still waiting for COMPLETE plus the required RF pruning counters before exiting early. ### Release note None ### Check List (For Author) - Test: Manual test - Ran git diff --check. - Tried ./run-regression-test.sh --run -d query_p0/runtime_filter -s rf_partition_pruning; local validation could not reach a Doris FE on 127.0.0.1:9030 and failed with Connection refused before suite assertions. - Behavior changed: No - Does this need documentation: No
Contributor
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 28625 ms |
Contributor
TPC-DS: Total hot run time: 168159 ms |
Contributor
FE Regression Coverage ReportIncrement line coverage |
Contributor
Author
|
/review |
Contributor
There was a problem hiding this comment.
I found two blocking correctness issues in the completion-state implementation.
Critical checkpoint conclusions:
- Goal: partially met. The PR adds a REST/list completion state and updates the RF pruning pollers, but the state is wrong for the Nereids execution path and can become inconsistent with the merged profile detail.
- Scope: the change is focused on profile completion and the affected regression tests.
- Concurrency: this code is concurrency-sensitive. BE profile reports and real-time profile fetches are merged asynchronously on
profile-write-pool; one race can leave the list state asCOMPLETEwhile the merged detail profile has been overwritten by an older non-final report. - Lifecycle/storage: spilled profiles persist the new terminal state, but with the missed Nereids backend-count path they can persist
INCOMPLETEafter all reports arrived. - Parallel code paths: classic
Coordinatorrecords fragment/backend expectations, but NereidsPipelineExecutionTaskconstruction does not, so the parallel path is not covered. - Tests: the added unit tests cover direct
ExecutionProfileuse, but they do not cover the Nereids execution-task path or real-time profile fetch racing after a final done report. I rangit diff --check FETCH_HEAD HEAD; I did not run FE/regression tests in this review pass. - Config/compatibility/security/transactions: no new config, security, transaction, or wire/storage-format compatibility issue found beyond old stored profiles returning
UNKNOWNas designed. - Observability/performance: no separate observability issue found; the Nereids bug can make the updated pollers wait their full timeout repeatedly.
User focus: no additional user-provided review focus was supplied.
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Nereids pipeline task construction did not register fragment/backend expectations in ExecutionProfile, so completed Nereids query profiles could remain in collecting or incomplete state. A later realtime non-final profile fetch could also overwrite the final done backend profile after completion. This change registers Nereids fragment/backend tasks in ExecutionProfile and rejects stale non-final backend profile updates after the final profile for that fragment/backend is recorded. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#completedBackendProfileRejectsLaterRealtimeProfile - ./run-fe-ut.sh --run org.apache.doris.qe.runtime.PipelineExecutionTaskBuilderTest#buildSingleFragmentPipelineTaskRegistersBackendWithExecutionProfile - git diff --check - Behavior changed: No - Does this need documentation: No
Contributor
Author
|
/review |
Contributor
Author
|
run buildall |
Contributor
There was a problem hiding this comment.
Review result: I found no additional blocking issues on the current head after reading the existing inline review threads. The current changes appear to address the known profile-completion concerns by tracking distinct done backends, rejecting stale non-done real-time profile updates after a backend has reported done, and registering expected backends for the Nereids task-builder path.
Critical checkpoint conclusions:
- Goal and tests: The PR adds a live/persisted profile completion state and updates RF pruning pollers to wait for
COMPLETE. Unit coverage was added for running/collecting/complete states, distinct backend reports, stale real-time updates, and Nereids backend registration. Regression pollers were updated accordingly. - Scope: The change is focused on FE profile metadata/completion tracking and the affected RF regression tests.
- Concurrency: This path is concurrent across REST profile reads,
profile-write-poolBE report merges, real-time profile fetches, and profile IO. The done-backend set and per-BE profile source are now updated under the samemultiBeProfileLock, and expected backend counts are populated before fragment RPCs are sent in both classic and Nereids paths. I did not find a new deadlock or stale-overwrite issue distinct from the already-known review context. - Lifecycle and persistence: Stored profiles now persist
COMPLETEorINCOMPLETEbefore memory release; older stored profiles without the field fall back toUNKNOWN. No special static/global lifecycle issue found. - Config and compatibility: No config item was added. The summary field is additive and does not introduce an FE-BE protocol/storage-format incompatibility requiring rolling-upgrade handling.
- Parallel code paths: Classic Coordinator and Nereids pipeline task construction now both register expected backend counts.
- Conditional checks: The
expectedBackendNum == 0branch preserves “not complete until expected backends are known”; I did not find another similar path missed by this PR. - Test results:
git diff --checkpassed. I attempted./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest,org.apache.doris.qe.runtime.PipelineExecutionTaskBuilderTest, but the runner checkout is missingthirdparty/installed/bin/protoc, so generated-source failed before Maven could run the tests. - Observability: Existing profile/report logs look sufficient for this change; no new metric seems necessary.
- Transactions/data writes: No transaction visibility, data-write, or EditLog behavior is touched.
- Performance: The added checks are lightweight and off the query execution hot path; no obvious new performance issue found.
User focus: no additional user-provided focus points were supplied.
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
TPC-H: Total hot run time: 29230 ms |
Contributor
TPC-DS: Total hot run time: 168575 ms |
zclllyybb
pushed a commit
to zclllyybb/doris
that referenced
this pull request
Jun 15, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile completion state queries inspect execution profiles while backend profile reports may still append fragment child profiles on the profile write pool. Checking the child list without holding RuntimeProfile's child lock can race with addChild. Move the completion check into RuntimeProfile so the child list size and done/cancel flags are read under the existing read lock. ### Release note None ### Check List (For Author) - Test: Manual test - git diff --check - Attempted ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList, but FE compilation failed before test execution due existing generated parser/proto mismatches unrelated to this change. - Behavior changed: No - Does this need documentation: No
zclllyybb
pushed a commit
to zclllyybb/doris
that referenced
this pull request
Jun 15, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile text generated before storage did not refresh the newly added profile completion state in the summary profile. When the same profile was written to storage, the storage path persisted the completion state and subsequent reads printed an extra summary line, making ProfilePersistentTest compare different strings. Refresh the display completion state before pretty-printing the summary, while keeping the existing storage-specific state used when persisting incomplete finished profiles. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfilePersistentTest#testGetOnStorageProfile - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList - git diff --check - Behavior changed: No - Does this need documentation: No
zclllyybb
pushed a commit
to zclllyybb/doris
that referenced
this pull request
Jun 15, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Profile completion state checked fragment RuntimeProfile child-node count against the expected backend count. A single backend report can add multiple child profile nodes, including a fragment-level profile and pipeline profiles, so the state could become COMPLETE before every backend report had been merged. Track the distinct backend addresses whose done reports have been merged for each fragment and use that count for completion. Add unit coverage for a two-backend fragment where the first backend contributes multiple profile nodes. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#profileCompletionStateWaitsForDistinctBackendReports - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#getProfileCompletionStateInQueryList - git diff --check - Behavior changed: No - Does this need documentation: No
zclllyybb
pushed a commit
to zclllyybb/doris
that referenced
this pull request
Jun 15, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: RF partition-pruning regression tests waited for Profile Completion State to become COMPLETE before reading the profile detail. Query completion and final profile merging are asynchronous, so the profile row can be visible while the completion state is still COLLECTING. In that window the poller returned an empty profile and failed with "Profile not found" even though the profile detail may already be readable. This change keeps the latest non-empty profile detail while still waiting for COMPLETE plus the required RF pruning counters before exiting early. ### Release note None ### Check List (For Author) - Test: Manual test - Ran git diff --check. - Tried ./run-regression-test.sh --run -d query_p0/runtime_filter -s rf_partition_pruning; local validation could not reach a Doris FE on 127.0.0.1:9030 and failed with Connection refused before suite assertions. - Behavior changed: No - Does this need documentation: No
zclllyybb
pushed a commit
to zclllyybb/doris
that referenced
this pull request
Jun 15, 2026
### What problem does this PR solve? Issue Number: None Related PR: apache#64392 Problem Summary: Nereids pipeline task construction did not register fragment/backend expectations in ExecutionProfile, so completed Nereids query profiles could remain in collecting or incomplete state. A later realtime non-final profile fetch could also overwrite the final done backend profile after completion. This change registers Nereids fragment/backend tasks in ExecutionProfile and rejects stale non-final backend profile updates after the final profile for that fragment/backend is recorded. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.common.profile.ProfileManagerTest#completedBackendProfileRejectsLaterRealtimeProfile - ./run-fe-ut.sh --run org.apache.doris.qe.runtime.PipelineExecutionTaskBuilderTest#buildSingleFragmentPipelineTaskRegistersBackendWithExecutionProfile - git diff --check - Behavior changed: No - Does this need documentation: No
zclllyybb
added a commit
that referenced
this pull request
Jun 15, 2026
…mpt (#64536) Problem Summary: Automated code review runs relied on the reviewer to infer which module-specific AGENTS.md files apply to a pull request. Recent Litefuse traces showed that reviews often skipped ancestor guides such as the repository root AGENTS.md, fe/AGENTS.md, and be/test/AGENTS.md even when the changed files made them applicable. This change fetches the PR changed file list, derives every existing AGENTS.md file from the changed file ancestor directories, records the list in the review context, and injects the required guide paths directly into the first Codex review prompt. We tested 5 PRs that did not read the AGENTS.md file during previous pipeline runs, and the new results are as follows: | Origin PR | Test PR | Run | Litefuse Trace | Result | |---|---:|---:|---|---| | #64478 | zclllyybb#36 | `27536249602` | `d76b77ac4e0d52d96f413b154c9f2571` | Read All | | #64458 | zclllyybb#37 | `27536258049` | `8db34388a8379acdcd9e48720f11225f` | Read All | | #64392 | zclllyybb#38 | `27536266784` | `a5e37fba03375a9517f7a67e33f70d39` | Read All | | #64489 | zclllyybb#39 | `27536275680` | `22ace18d70ece96b0ca7fa73123b62da` | Read All | | #64419 | zclllyybb#41 | `27538239601` | `1803c040e4140d61e840e4e1526190e7` | Read All |
Mryange
approved these changes
Jun 16, 2026
Contributor
|
PR approved by at least one committer and no changes requested. |
github-actions
Bot
added
the
approved
924060929
added a commit
that referenced
this pull request
Jun 22, 2026
…ster's Profile Completion State master #64392 already added a profile-completion mechanism (Profile Completion State: RUNNING/COLLECTING/COMPLETE, wired in Profile.java, tested in ProfileManagerTest). Our IS_PROFILE_COLLECTION_COMPLETED marker duplicated it (and had no reader), so remove it and make the profile_plan_tree plugin poll master's 'Profile Completion State: COMPLETE' instead of a fixed sleep.
924060929
added a commit
that referenced
this pull request
Jun 22, 2026
…file Completion State field The previous text-regex on /api/profile/text was unverified — master (#64392) exposes the completion state as a structured field of /rest/v1/query_profile (item['Profile Completion State'] == 'COMPLETE'), the same way its RF-pruning test polls it. Use ProfileAction.getProfileList() and match by Profile ID == query id, then fetch the profile text to build the tree.
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
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?
Issue Number: None
Related PR: None
Problem Summary: Runtime-filter partition-pruning regression tests read FE query profiles immediately after query completion. Query completion does not guarantee that asynchronous BE profile reports have been merged, so the tests can see RF pruning counters before their final values and fail with zero partition counters. This change exposes a profile completion state in the query profile REST list based on ExecutionProfile.isCompleted(), persists the terminal state before profile spill, and updates the RF pruning profile pollers to wait for COMPLETE before reading counter values.
Release note
None
Check List (For Author)