Skip to content

[test](regression) Stabilize test_auto_new_recycle and test_sql_digest_generation - #70308

Merged
Gabriel39 merged 1 commit into
apache:masterfrom
morningman:b2m-t55-p0-test-stability
Nov 6, 2026
Merged

Gabriel39 merged 1 commit into
apache:masterfrom
morningman:b2m-t55-p0-test-stability

Conversation

@morningman

Copy link
Copy Markdown
Contributor

Background

An auto-partition table with partition.retention_count = N keeps only its N latest historical partitions: the FE's DynamicPartitionScheduler drops older ones on every run, once per dynamic_partition_check_interval_seconds (600 by default). partition_p0/auto_partition/test_auto_new_recycle lowers that interval to 1 s and checks the partition count after each load or ALTER. audit/test_sql_digest_generation checks that the audit log gets an sql_digest only for queries slower than the FE config sql_digest_generation_threshold_ms, once with the threshold at 0 and once at 100000. Both suites are in group nonConcurrent.

What problem does this PR solve?

Issue Number: None
Related PR: #65375 and #65646 (the branch-4.1 recycle-suite fixes by @shuke987, ported here), #65343 (the branch-4.1 digest-suite fix by @shuke987, ported here), #65435 (master's earlier move of the recycle suite's day-boundary guard)
PR Type: Test

Problem Summary:

Both suites rely on timing the product does not promise. The recycle suite checks the partition count after a fixed sleep(8000) (5 s after an ALTER), while the drop happens asynchronously at an unbounded time after the config change; branch-4.1's NonConcurrent pipeline failed at the first such check repeatedly (#65375). The digest suite's threshold-0 check needs the query's elapsed time to be above 0 ms. This PR gives both suites their branch-4.1/4.2 form: the recycle suite polls the partition count every second, for at most 1200 s, and widens its day-boundary guard to cover the poll; the digest query adds sleep(1). Both files become identical to branch-4.2.

Details

  • Failure: On master's public NonConcurrent pipeline neither suite has failed on its own since mid-July: of about 8,000 runs each, the recycle suite failed 3 times and the digest suite 87 times, all in builds whose cluster had died (most suites failing). The failures that motivated the fixes are on branch-4.1's pipeline ([fix](regression) Wait for auto partition recycle #65375); [fix](test) stabilize sql digest generation case #65343 made the digest query deterministic there.
  • Cause: ADMIN SET FRONTEND CONFIG sets the scheduler's new interval at once, but the scheduler sleeps in 5-second slices and notices the change only at the next slice. It then runs executeDynamicPartition over every registered table before the drop. So the drop lands 0 to 5 s plus one full pass after the config change, and a pass longer than about 3 s fails the 8-second check. In the digest suite, AuditLogHelper writes a digest only when elapseMs > sql_digest_generation_threshold_ms, and nothing bounds the elapsed time of select * on a two-row table from below (9 to 15 ms locally). With sleep(1) on each row it takes about 2 s, still far below the second check's 100000 ms.
  • Stability evidence: The recycle checks now wait for the drop and fail only when the count misses the target for 1200 s. The poll runs on the suite thread, because the framework sets Awaitility.pollInSameThread() ([fix](remote-doris) End a remote Doris scan's Flight SQL session with the query; stop the regression framework leaking connections #68338), so it does not leak connections. Shortening one of master's waits to 1 s reproduces the branch-4.1 failure shape, and the ported suite passes; mutants show that both suites still catch wrong results (see Testing).

Testing

All runs used ./run-regression-test.sh --run -d partition_p0/auto_partition -s test_auto_new_recycle or --run -d audit -s test_sql_digest_generation against a local single-FE, single-BE cluster built from master.

Suite Version Result
test_auto_new_recycle master passes
test_auto_new_recycle this PR passes; the polls reached the target after 1, 2, 1, 3 and 3 s
test_auto_new_recycle master, with the wait before the 10-partition check cut to 1 s fails as #65375 describes: expected: <101> but was: <10> (master's assertEquals has its arguments swapped, so 101 partitions were still there)
test_auto_new_recycle this PR, expecting 11 partitions, poll capped at 20 s fails as it should: ConditionTimeoutException
test_sql_digest_generation master passes
test_sql_digest_generation this PR passes; the query took 2,024 and 2,025 ms
test_sql_digest_generation this PR, second threshold 1000 ms fails as it should: Count of sql_digest changed

The PR NonConcurrent pipeline runs both suites; cloud_p0 skips nonConcurrent suites.

Notes for Reviewers

Release note

None

Check List (For Author)

  • Behavior changed: No
  • Does this need documentation: No
  • Pre-submission status: Ready

AI Disclosure

  • Tool: Claude Code (Claude Opus 5.5)
  • Generated: the port (both suites taken from branch-4.2), the local verification runs, and this description
  • Human review: not stated
  • Prompts: The author asked to continue moving branch-4.2's changes back to master, where six branch-4.1 test fixes were recorded as one task. After the check showed that master already covers four of them and has not failed on the other two, the author chose to port those two exactly as branch-4.2 has them and to verify them on a local cluster.

…t_generation

### Background

An auto-partition table with `partition.retention_count = N` keeps only its N latest historical partitions: the FE's `DynamicPartitionScheduler` drops older ones on every run, once per `dynamic_partition_check_interval_seconds` (600 by default). `partition_p0/auto_partition/test_auto_new_recycle` lowers that interval to 1 s and checks the partition count after each load or ALTER. `audit/test_sql_digest_generation` checks that the audit log gets an `sql_digest` only for queries slower than the FE config `sql_digest_generation_threshold_ms`, once with the threshold at 0 and once at 100000. Both suites are in group `nonConcurrent`.

### What problem does this PR solve?

Issue Number: None
Related PR: apache#65375 and apache#65646 (the branch-4.1 recycle-suite fixes by @shuke987, ported here), apache#65343 (the branch-4.1 digest-suite fix by @shuke987, ported here), apache#65435 (master's earlier move of the recycle suite's day-boundary guard)
PR Type: Test

Problem Summary:

Both suites rely on timing the product does not promise. The recycle suite checks the partition count after a fixed `sleep(8000)` (5 s after an ALTER), while the drop happens asynchronously at an unbounded time after the config change; branch-4.1's NonConcurrent pipeline failed at the first such check repeatedly (apache#65375). The digest suite's threshold-0 check needs the query's elapsed time to be above 0 ms. This PR gives both suites their branch-4.1/4.2 form: the recycle suite polls the partition count every second, for at most 1200 s, and widens its day-boundary guard to cover the poll; the digest query adds `sleep(1)`. Both files become identical to branch-4.2.

### Details

- **Failure:** On master's public NonConcurrent pipeline neither suite has failed on its own since mid-July: of about 8,000 runs each, the recycle suite failed 3 times and the digest suite 87 times, all in builds whose cluster had died (most suites failing). The failures that motivated the fixes are on branch-4.1's pipeline (apache#65375); apache#65343 made the digest query deterministic there.
- **Cause:** `ADMIN SET FRONTEND CONFIG` sets the scheduler's new interval at once, but the scheduler sleeps in 5-second slices and notices the change only at the next slice. It then runs `executeDynamicPartition` over every registered table before the drop. So the drop lands 0 to 5 s plus one full pass after the config change, and a pass longer than about 3 s fails the 8-second check. In the digest suite, `AuditLogHelper` writes a digest only when `elapseMs > sql_digest_generation_threshold_ms`, and nothing bounds the elapsed time of `select *` on a two-row table from below (9 to 15 ms locally). With `sleep(1)` on each row it takes about 2 s, still far below the second check's 100000 ms.
- **Stability evidence:** The recycle checks now wait for the drop and fail only when the count misses the target for 1200 s. The poll runs on the suite thread, because the framework sets `Awaitility.pollInSameThread()` (apache#68338), so it does not leak connections. Shortening one of master's waits to 1 s reproduces the branch-4.1 failure shape, and the ported suite passes; mutants show that both suites still catch wrong results (see Testing).

### Testing

All runs used `./run-regression-test.sh --run -d partition_p0/auto_partition -s test_auto_new_recycle` or `--run -d audit -s test_sql_digest_generation` against a local single-FE, single-BE cluster built from master.

| Suite | Version | Result |
|---|---|---|
| `test_auto_new_recycle` | master | passes |
| `test_auto_new_recycle` | this PR | passes; the polls reached the target after 1, 2, 1, 3 and 3 s |
| `test_auto_new_recycle` | master, with the wait before the 10-partition check cut to 1 s | fails as apache#65375 describes: `expected: <101> but was: <10>` (master's `assertEquals` has its arguments swapped, so 101 partitions were still there) |
| `test_auto_new_recycle` | this PR, expecting 11 partitions, poll capped at 20 s | fails as it should: `ConditionTimeoutException` |
| `test_sql_digest_generation` | master | passes |
| `test_sql_digest_generation` | this PR | passes; the query took 2,024 and 2,025 ms |
| `test_sql_digest_generation` | this PR, second threshold 1000 ms | fails as it should: `Count of sql_digest changed` |

The PR NonConcurrent pipeline runs both suites; cloud_p0 skips `nonConcurrent` suites.

### Notes for Reviewers

- The day-boundary guard before the final `now()`-based section goes from 100 s to 1300 s, as in apache#65646, so that it covers the 1200 s poll plus the insert and checks. It sleeps only when that section would otherwise start within 1300 s of midnight.
- Four more suites fixed in the same branch-4.1 batch need nothing on master: apache#65340 (master apache#68449 enables the publish debug point on all FEs, superseding the open port apache#65556), apache#65929 (master apache#68329 fixed the actual cause, a connection leak), apache#65885 (master apache#69723 removed the V1 scanner whose message it also accepted), and apache#67363 (ported as apache#67402).

### Release note

None

### Check List (For Author)

- Behavior changed: No
- Does this need documentation: No
- Pre-submission status: Ready

### AI Disclosure

- Tool: Claude Code (Claude Opus 5.5)
- Generated: the port (both suites taken from branch-4.2), the local verification runs, and this description
- Human review: not stated
- Prompts: The author asked to continue moving branch-4.2's changes back to master, where six branch-4.1 test fixes were recorded as one task. After the check showed that master already covers four of them and has not failed on the other two, the author chose to port those two exactly as branch-4.2 has them and to verify them on a local cluster.

Co-authored-by: shuke <shuke@selectdb.com>
Co-Authored-By: Claude Opus 5.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?

@morningman

Copy link
Copy Markdown
Contributor Author

run buildall

@morningman

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static review of PR 70308 at head 77459c4 against base 52362a4 completed after two review rounds. No new inline findings were verified, no existing review threads were present, and no P0/P1 finding remains applicable.

The task goal is met by the changed regression suites: the digest query uses the registered non-constant Sleep function so the threshold-0 path has deterministic elapsed time while the 100000 ms path remains negative; the auto-recycle suite polls the eventual SHOW PARTITIONS state and the day-boundary guard covers the bounded final scenario. The helper is same-thread and reuses the suite connection, and the scheduler interval is restored at the existing cleanup points.

Critical checkpoints: the modification is focused to two regression suites and uses existing framework helpers; no product concurrency, lifecycle, protocol, persistence, or storage-format path is changed. The only asynchronous path is the existing FE dynamic-partition scheduler, whose interval update and current-time filtering were traced; the Awaitility helper has a finite bound and a timeout aborts the suite. All changed call sites, parallel test paths, explicit ordering, and error-test conventions were inspected. The changed SQL sleep is limited to the two-row table and the polling logs partition counts at one-second intervals. No new observability or compatibility mechanism is needed for these test-only changes.

User review focus: none was supplied. Validation is static inspection only; no builds or regression tests were run under the review contract. No unresolved coverage gap remains.

Review converged after 3 round(s).

@morningman

Copy link
Copy Markdown
Contributor Author

run p0

@Gabriel39
Gabriel39 merged commit dcf8285 into apache:master Nov 6, 2026
38 checks passed
@github-actions

github-actions Bot commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Nov 6, 2026
@github-actions

github-actions Bot commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

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

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. backport/4.2-master reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants