[branch-4.1][fix](test) Extend JDBC catalog sync timeout by hello-stephen · Pull Request #65929 · apache/doris

hello-stephen · 2026-07-22T17:35:45Z

Proposed changes

extend the bounded JDBC catalog table-sync wait from 10 seconds to 60 seconds
log the catalog/database name and last SQL exception through the suite logger while polling

Root cause

S3 P0 build 203802 created the JDBC catalog successfully, but the first metadata discovery did not expose tables within the fixed 10-second window. A sibling lower-case catalog test succeeded in the same cluster, so this is a case-level cold metadata/driver timing issue rather than a cluster-wide outage.

Validation

git diff --check
scoped to one regression case; product behavior and assertions are unchanged

Jira: DORIS-27397
TeamCity: http://172.20.48.17:8111/buildConfiguration/Doris_Doris_x64_branch41_S3_Regression_P0/203802
Occurrence: build:(id:203802),id:2000001232

hello-stephen · 2026-07-22T17:35:51Z

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:

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

hello-stephen · 2026-07-24T03:27:34Z

run compile

hello-stephen · 2026-07-24T07:41:26Z

[external-only-ci-1004593-terminal]

Community Compile #1004480 finished SUCCESS. This PR only changes external_table_p0.lower_case.test_lower_case_meta_with_lower_table_conf_show_and_select, so the fan-out was intentionally narrowed to the matching External pipeline to avoid consuming concurrent regression capacity on unrelated P0/Cloud/NonConcurrent suites:

External #1004593: finished SUCCESS, 567 passed / 1 muted
target occurrence external_table_p0.lower_case.test_lower_case_meta_with_lower_table_conf_show_and_select.test_lower_case_meta_with_lower_table_conf_show_and_select: SUCCESS, 104958 ms
P0 #1004592, cloud_p0 #1004594, NonConcurrent #1004596: intentionally canceled after fan-out
Vault #1004595: finished SUCCESS before cancellation

The target runtime proof is complete for this PR head. skip buildall below is only the cost-control signal for the remaining unrelated fan-out; it does not replace the required post-merge branch-4.1 exact-case rerun.

hello-stephen · 2026-07-24T07:41:27Z

skip buildall

hello-stephen · 2026-07-24T07:41:30Z

/review

github-actions · 2026-07-24T08:02:21Z

Codex automated review failed and did not complete.

Error: You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at Jul 30th, 2026 7:58 AM.
Workflow run: https://github.com/apache/doris/actions/runs/30076304873

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

@shuke987

…t_generation (#70308) ### 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 (#65375); #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()` (#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 - The day-boundary guard before the final `now()`-based section goes from 100 s to 1300 s, as in #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: #65340 (master #68449 enables the publish debug point on all FEs, superseding the open port #65556), #65929 (master #68329 fixed the actual cause, a connection leak), #65885 (master #69723 removed the V1 scanner whose message it also accepted), and #67363 (ported as #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>

fix(test): extend JDBC catalog sync timeout

3dfa725

hello-stephen requested a review from morningman July 22, 2026 17:36

hello-stephen marked this pull request as ready for review July 24, 2026 07:41

hello-stephen requested a review from yiguolei as a code owner July 24, 2026 07:41

yiguolei approved these changes Jul 24, 2026

View reviewed changes

yiguolei merged commit aafbf2f into apache:branch-4.1 Jul 24, 2026
32 of 35 checks passed

hello-stephen deleted the agent/doris-27397-jdbc-catalog-timeout branch July 24, 2026 08:37

morningman mentioned this pull request Nov 5, 2026

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

Merged

Navigation Menu

Repository navigation

[branch-4.1][fix](test) Extend JDBC catalog sync timeout - #65929

[branch-4.1][fix](test) Extend JDBC catalog sync timeout#65929
yiguolei merged 1 commit into
apache:branch-4.1from
hello-stephen:agent/doris-27397-jdbc-catalog-timeout

hello-stephen commented Jul 22, 2026

Uh oh!

hello-stephen commented Jul 22, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

github-actions Bot commented Jul 24, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

hello-stephen commented Jul 22, 2026

Proposed changes

Root cause

Validation

Uh oh!

hello-stephen commented Jul 22, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

github-actions Bot commented Jul 24, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants