branch-4.1: [fix](regression) handle E-2010 compaction wait#65290
Conversation
…pache#64945) # [fix](regression) handle cumulative delete-version compaction wait ## Summary Fix `trigger_and_wait_compaction` so Cloud cumulative compaction that meets a delete version does not wait until the 300s timeout after valid progress has already happened. When cumulative compaction meets a delete version, BE can return `[E-2010] cumulative compaction meet delete version`, advance the cumulative point, and let base compaction handle the rowsets. In that path the cumulative success/failure timestamps may not change, so the old helper kept polling even after base compaction had completed and `run_status=false`. This patch treats `E-2010` plus cumulative point advancement plus a changed base success time as an equivalent completed cumulative delete-version path while still waiting when `run_status=true`. If `E-2010` advances the cumulative point but base success time has not changed yet, the helper keeps waiting even if the cumulative failure timestamp changed. ## Root Cause The case `compaction/test_compacation_with_delete.groovy` creates alternating data and delete rowsets, then calls `trigger_and_wait_compaction(tableName, "cumulative")`. In Cloud mode this can legally follow: 1. cumulative compaction meets delete version and returns `E-2010` 2. cumulative point advances 3. base compaction handles the delete-version rowsets The helper only watched cumulative success/failure timestamp changes. In the failing log, base compaction completed in 448 ms, but the helper waited for 5 minutes because the cumulative timestamps did not change. ## Validation - `git diff --check` - `git diff --check origin/master..HEAD` - Local Groovy condition simulation: - `E-2010 + cumulative point advanced + base success time changed + run_status=false` exits wait - `E-2010 + cumulative point advanced` keeps waiting if base success time has not changed - `E-2010 + cumulative point advanced + cumulative failure time changed` still keeps waiting if base success time has not changed - `run_status=true` keeps waiting even if the delete-version/base-success condition is met - normal cumulative success timestamp change still exits wait when there is no delete-version handoff Cloud P0 rerun is still needed for final validation. (cherry picked from commit 4f8c144)
Related PR: apache#64945 Problem Summary: `trigger_and_wait_compaction` has special handling for cumulative compaction that meets delete-version rowsets and reports `E-2010`. PR apache#64945 made the helper wait for base compaction success before treating that handoff as finished. Build `985491` exposed another valid timing window in `compaction/test_compaction_agg_keys_with_delete.groovy`: for tablet `1783077858744`, base success was already visible in the cached old tablet status, while cumulative success advanced later. The final polled state was not stuck: - `run_status=false` - `cumulative point` advanced from `7` to `12` - `last cumulative status` changed to `[E-2010]cumulative compaction meet delete version` - `last cumulative success time` advanced from `2026-07-03 19:46:16.439` to `2026-07-03 19:46:16.945` - rowsets were compacted from separate `[8-8]`, `[9-9]`, `[10-10]` rowsets to `[8-10]` However, the helper only accepted the E-2010 handoff when `last base success time` changed after the cached old status. In this timing window that timestamp did not change, so the helper kept returning "still running" until the 5-minute Awaitility timeout. This patch keeps the previous safety guard: E-2010 plus cumulative point movement alone is still not enough. It now accepts the handoff when either base success time changes or cumulative success time changes, so a pure E-2010 failure timestamp change is not treated as completion. (cherry picked from commit 9012d3b)
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review completed for PR #65290 at head f0971dc.
I found one blocking issue in the regression compaction helper: the E-2010 delete-version handoff can now be treated as complete based on Cloud EMPTY_CUMULATIVE's own cumulative success timestamp, before base compaction has necessarily merged the rowsets that the tests inspect.
Critical checkpoints: the changed-file list contains only regression-test/plugins/plugin_compaction.groovy; no existing inline review threads were present; no required AGENTS.md files were listed for this PR; GitHub PR file metadata and the fetched base/head range agree on the single-file patch; git diff --check on the fetched PR range is clean. I did not run the branch-4.1 regression suite in this runner.
User focus: no additional user-provided review focus was supplied.
Subagent conclusions: optimizer-rewrite found no optimizer/rewrite candidate. tests-session-config proposed TSC-001, which was independently verified and accepted as MRG-001. Convergence round 1 completed with both live subagents returning NO_NEW_VALUABLE_FINDINGS for the unchanged final ledger/comment set.
| newCumulativePoint > oldCumulativePoint | ||
| completedByBaseCompactionAfterDeleteVersion = | ||
| handedOffToBaseCompactionAfterDeleteVersion && | ||
| (baseSuccessTimeChanged || cumulativeSuccessTimeChanged) |
There was a problem hiding this comment.
This completion check can fire too early in the E-2010 handoff path. In Cloud, the handoff is committed as an EMPTY_CUMULATIVE job; meta-service explicitly treats that as a metadata-only update to the cumulative point/count, but it also sets last_cumu_compaction_time_ms, which BE exposes as last cumulative success time. With this || cumulativeSuccessTimeChanged, the helper can return right after the empty cumulative handoff, before the base compaction that actually merges the delete-version rowsets has run. The affected tests inspect rowsets immediately after this helper returns, so this reintroduces the flaky early-exit window. Please keep this fast path tied to a base-compaction completion signal, or add another rowset/base-completion check before accepting cumulative success time here.
3 participants
Summary
Testing