Skip to content

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

Merged
morningman merged 1 commit into
branch-4.0from
auto-pick-64419-branch-4.0
Jun 30, 2026
Merged

branch-4.0: fix(regression): Make test_analyze_mv row_count assertion stable after truncate #64419#64501
morningman merged 1 commit into
branch-4.0from
auto-pick-64419-branch-4.0

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>
@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

@github-actionsgithub-actionsBot added the approved Indicates a PR has been approved by one committer. label Jun 24, 2026
@github-actions

Copy link
Copy Markdown
ContributorAuthor

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

@github-actions

Copy link
Copy Markdown
ContributorAuthor

PR approved by anyone and no changes requested.

@morningmanmorningman reopened this Jun 30, 2026
@morningman
morningman merged commit cf09a31 into branch-4.0Jun 30, 2026
40 of 46 checks passed
@github-actions
github-actionsBot deleted the auto-pick-64419-branch-4.0 branch June 30, 2026 10:06
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approvedIndicates a PR has been approved by one committer.reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@hello-stephen@morningman@yujun777