Skip to content

branch-4.1: fix(regression): Make test_analyze_mv row_count assertion stable after truncate #64419#64503

Merged
yiguolei merged 1 commit into
branch-4.1from
auto-pick-64419-branch-4.1
Jun 16, 2026
Merged

branch-4.1: fix(regression): Make test_analyze_mv row_count assertion stable after truncate #64419#64503
yiguolei merged 1 commit into
branch-4.1from
auto-pick-64419-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #64419

…r truncate (#64419)

## Problem

`statistics/test_analyze_mv.groovy` line 614 asserts `assertEquals("-1",
result_row[0][4])` immediately after `truncate table`, expecting
`report_row_count_for_nereids` to be -1 (unreported). This is a race
condition: BE asynchronously reports new tablet stats (0 rows for empty
table) to FE, and if the report arrives before the assertion, the value
is 0 instead of -1.

On cloud, this is amplified by `CloudTabletStatMgr` unconditionally
setting `rowCountReported=true`, making the -1 state exceptionally
short-lived or unobservable.

## Root Cause

After `truncate table`, the FE stat manager (`CloudTabletStatMgr` /
`TabletStatMgr`) updates `MaterializedIndex.rowCount` and sets
`rowCountReported=true`. The test assertion races with this update:
- If BE hasn't reported yet → `getRowCountForIndex(id, true)` returns -1
✓
- If BE has reported → returns 0 ✗ (test fails)

## Fix

Change the assertion to accept both -1 and 0, since both are valid
states for an empty table after truncate:
- -1: tablet row count not yet reported
- 0: tablet row count reported as 0 (empty table)

Add assertion message with actual value for debuggability.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@github-actions
github-actions Bot requested a review from yiguolei as a code owner June 15, 2026 04:19
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@yujun777

Copy link
Copy Markdown
Contributor

run p0

@yujun777

Copy link
Copy Markdown
Contributor

run nonConcurrent

@yiguolei yiguolei closed this Jun 16, 2026
@yiguolei yiguolei reopened this Jun 16, 2026
@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Jun 16, 2026
@github-actions

Copy link
Copy Markdown
Contributor Author

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

@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by anyone and no changes requested.

@yiguolei
yiguolei merged commit faeb982 into branch-4.1 Jun 16, 2026
32 of 44 checks passed
@morningman
morningman deleted the auto-pick-64419-branch-4.1 branch July 8, 2026 14:10
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. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants