Antalya 25.8: Bump to 25.8.33

[zvonand]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [46d077a]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2287 (Bump to 25.8.33)

Verdict — 6 red checks: 1 PR-related & fixable, 1 flaky, 2 pre-existing (same swarms failure), plus the PR aggregate gate and DCO (both expected on a bump).

Check	Class	PR-caused?
Stateless (amd_binary, ParallelReplicas, s3, parallel) — 04743_trivial_count_array_join_argument	test gap in a newly-backported test	Yes — fixable
Stateless (amd_binary, old analyzer, s3, DatabaseReplicated, seq) — 01079_parallel_alter_detach_table_zookeeper	flaky (distributed-DDL timeout)	No
Regression x86 swarms / RegressionTestsRelease / Swarms / swarms (same run)	pre-existing Antalya swarm-join issue	No
PR	aggregate gate — red only because the above are red	—
DCO	29 inherited upstream/backport commits lack Signed-off-by	expected on a bump

---

1. 04743_trivial_count_array_join_argument — PR-related, deterministic ✅ fixable

Only fails in the ParallelReplicas variant (Failed: 1, Passed: 7187). Exactly one output line differs:

@@ -5,16 +5,16 @@
 ...
 0
-1
+0
 1 1 6 6 3

That line is the plan probe:

SELECT count() > 0 FROM (EXPLAIN SELECT count(arrayJoin(A)) FROM t_04743 SETTINGS optimize_trivial_count_query = 1)
WHERE explain ILIKE '%ReadFromMergeTree%';

Under parallel replicas the read step is ReadFromRemoteParallelReplicas, not ReadFromMergeTree, so the probe returns 0 instead of 1. The row-count arms (lines 1–13) are unaffected — only the EXPLAIN plan-shape assertion is.

This test was newly introduced to antalya-25.8 by this bump (backport ClickHouse#115227, commit 77b6ebb; unnest arms dropped in 0713259), so the failure is introduced by this PR, not pre-existing. It carries a no-old-analyzer guard for the same reason (its plan assertions are analyzer/plan-specific) but no parallel-replicas guard.

Concrete fix — add the standard no-parallel-replicas tag (23 other stateless tests already use it), mirroring the existing no-old-analyzer guard:

 #!/usr/bin/env bash
-# Tags: no-old-analyzer
+# Tags: no-old-analyzer, no-parallel-replicas
 # no-old-analyzer: The plan assertions describe applyTrivialCountIfPossible; the old analyzer decides trivial count in TreeRewriter
+# no-parallel-replicas: the EXPLAIN plan asserts on ReadFromMergeTree, which parallel replicas replaces with ReadFromRemoteParallelReplicas

2. 01079_parallel_alter_detach_table_zookeeper — flaky, not PR-caused ❌

Fails in the DatabaseReplicated sequential variant with:

Code: 159. DB::Exception: ReplicatedDatabase DDL task ...query-0000000014 is not finished on 1 of 3 hosts ...
Was waiting for 120.87s, which is longer than distributed_ddl_task_timeout. (TIMEOUT_EXCEEDED)

on DROP TABLE ... concurrent_alter_detach_1. This is a distributed-DDL timeout under the (slow, 3-host) DatabaseReplicated config — the classic flaky signature for this test. Nothing in the 25.8.33 bump touches ReplicatedDatabase DDL. Safe to re-run.

3. Swarms regression (Regression x86 swarms = RegressionTestsRelease / Swarms / swarms) — pre-existing, not PR-caused ❌

12 features (9 ok, 3 failed); 1521 scenarios (1380 ok, 109 failed). All 109 failures are in one branch: swarm joins / join clause — JOINs between object-storage tables (iceberg / parquet / s3) and MergeTree in swarm clusters. No connectivity/timeout/node-join errors; every failure is a query exit-code/result mismatch, and one whole strand is tied to a known, tracked product bug, Altinity #1244 (the test itself expects exit 81/10 and comments the issue link). These are Antalya-specific swarm-join features maintained on the branch, not touched by this upstream bump (the diff is version/libssh/src backports + test files). This suite is red on the branch independent of this PR. Worth a re-run to confirm the exact count, but not something #2287 should block on or fix.

4. PR and DCO

• PR is the aggregate gate; it turns green once the real checks above are addressed/re-run.
• DCO lists 29 commits without Signed-off-by — all inherited upstream/backport commits (Backport #… to 25.8, version-bump, and origin/25.8 merges), none authored in this PR. That's normal for a bump. The only "fix" DCO offers is a git rebase --signoff + force-push rewriting ~60 commits of shared history, which I will not do (destructive, and against policy). This is for a human maintainer to waive/override as usual for bump PRs.

---

Only #1 is a genuine, actionable PR-related failure. Per policy I haven't pushed anything. Want me to (a) open a blau/* PR with the 04743 tag fix, or (b) commit it directly to bump/antalya-25.8/25.8.33? The other reds are flaky/pre-existing/expected — a re-run should clear #2, and #3/#4 are pre-existing.

[zvonand]

@blau-ai fix 04743_trivial_count_array_join_argument in this branch

[blau-ai]

@zvonand — fixed 04743_trivial_count_array_join_argument. Committed directly to this branch (bump/antalya-25.8/25.8.33) as you asked; if you'd rather I'd delivered it as a separate PR, say the word and I'll move it.

Commit: 46d077a

What failed

The test failed in exactly one suite — Stateless tests (amd_binary, ParallelReplicas, s3 storage, parallel) (Failed: 1). The diff was a single line:

 0
-1
+0
 1

That is reference line 15, the plan-shape assertion:

SELECT count() > 0 FROM (EXPLAIN SELECT count(arrayJoin(A)) FROM t_04743 SETTINGS optimize_trivial_count_query = 1)
WHERE explain ILIKE '%ReadFromMergeTree%';   -- expected 1

Root cause

Under the ParallelReplicas profile the suite runs with enable_parallel_replicas=1 / parallel_replicas_for_non_replicated_merge_tree=1, so count(arrayJoin(A)) reads through a remote-replicas step instead of ReadFromMergeTree. The ILIKE '%ReadFromMergeTree%' check therefore returned 0. The other three plan checks (Optimized trivial count markers) are planner-level and were unaffected — only the physical read-step check broke.

Fix

The feature under test (trivial-count refusal when the aggregate argument contains arrayJoin) is a planner behavior independent of parallel replicas, so I pinned the four EXPLAIN plan-shape queries with enable_parallel_replicas = 0. This asserts on the deterministic local plan while leaving all the value checks running unchanged under every profile. No reference update was needed.

-SELECT count() > 0 FROM (EXPLAIN SELECT count(arrayJoin(A)) FROM t_04743 SETTINGS optimize_trivial_count_query = 1)
+SELECT count() > 0 FROM (EXPLAIN SELECT count(arrayJoin(A)) FROM t_04743 SETTINGS optimize_trivial_count_query = 1, enable_parallel_replicas = 0)
 WHERE explain ILIKE '%ReadFromMergeTree%';

(same , enable_parallel_replicas = 0 added to the other three EXPLAINs).

Validated by CI on this branch — I can't build/run ClickHouse in this container.

Unrelated note

The other red stateless suite (amd_binary, old analyzer, DatabaseReplicated, sequential) failed on a different test — 01079_parallel_alter_detach_table_zookeeper — with a DROP TABLE TIMEOUT_EXCEEDED (Code 159) on a DatabaseReplicated DDL. That's a replicated-DDL timeout/flake, unrelated to 04743 and to this fix; 04743 is no-old-analyzer-tagged and is skipped in that suite. Left untouched — let me know if you want me to look at it separately.

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2287 (bump to 25.8.33)

Verdict: No failure points at a real bug introduced by this bump. Breakdown of the red checks:

• 0 caused by this PR's code
• 1 pre-existing / known — swarm-join regression failures (tracked in existing issues)
• 1 test-robustness (new heavy test brought in by the bump) — the ASan flaky check
• ~16 infra / runner — "Job failed to produce Result" + one error shard
• 1 process — DCO sign-off

The PR check is just the aggregate gate rolling up the items below.

---

1. Regression swarms — pre-existing / known (not this bump)

Regression x86 swarms and RegressionTestsRelease / Swarms / swarms: 12 features (9 ok, 3 failed), 1521 scenarios (1380 ok, 109 failed, 32 xfail).

Every one of the 109 failures is in the same place — /swarms/feature/swarm joins/join clause/… in allow mode … — with a bare AssertionError (result mismatch). This matches already-open swarm-join bugs on the antalya-25.8 line:

• Swarm join in allowed mode failed with Not found column in block on 25.8.12.20678.altinityantalya #1244 — Swarm join in allowed mode failed … (open, antalya)
• Swarm joins unexpected bad get: has Int64, requested Decimal64 #1202 — Swarm joins unexpected bad get: has Int64, requested Decimal64 (open, antalya, swarms)

Why the earlier bump (#2224 → 25.8.30) showed swarms green: clickhouse-regression is pulled fresh from its own main at run time, and the swarm joins matrix has been expanded since then, so it now exercises the broken combinations. This is a pre-existing swarm-feature problem, not something the version/libssh bump introduced.

Next step: doesn't block the bump on its own merits; track under #1244/#1202. If you want confirmation of a specific case, tfs show messages on join 26 of 816480 … INNER JOIN … in allow mode from that job's test.log.

2. Stateless tests (amd_asan, flaky check) — new heavy test, times out under sanitizer

Result: Failed: 0, Passed: 599, Skipped: 0, Broken: 1, overall FAIL = "Some queries hung".

The one broken test is 04895_parquet_dictionary_source_prefetch_lifetime, new in this bump. broken_tests_handler.log:

Reason: Timeout! Processes left in process group 17816
Matched rule: {'reason': 'KNOWN: Random timeout with sanitizer', ... 'check_types': ['tsan','asan','msan','ubsan']}

The test inserts 2,000,000 rows and does 5 forced SYSTEM RELOAD DICTIONARY with max_download_threads=32, max_parsing_threads=32. That's fine in a normal build but times out under ASan in the flaky check (which runs changed tests repeatedly). It's classified as a known random sanitizer timeout, not a correctness failure — so this is test robustness, not a product bug. The test currently only carries # Tags: no-fasttest.

Suggested fix (present-only; not pushed — see bottom):

--- a/tests/queries/0_stateless/04895_parquet_dictionary_source_prefetch_lifetime.sh
+++ b/tests/queries/0_stateless/04895_parquet_dictionary_source_prefetch_lifetime.sh
@@
 #!/usr/bin/env bash
-# Tags: no-fasttest
+# Tags: no-fasttest, long
 # no-fasttest: needs the Parquet format which is not built in fasttest.
+# long: inserts millions of rows and force-reloads the dictionary repeatedly; slow under sanitizers.

Keep the ASan coverage (this test is specifically about use-after-free during pipeline teardown, so a sanitizer run is the point — don't no-asan it). The long tag grants the longer timeout that avoids the hang. Optionally also drop numbers(2000000) → numbers(500000) (still 100 row groups at output_format_parquet_row_group_size = 5000, so it keeps "many read ranges / many queued tasks").

3. ~16 jobs: "Job failed to produce Result due to a script error or CI runner issue" — infra

These stateless/stress jobs errored before producing any result (no logs uploaded): amd_asan distributed plan parallel 1/2 + sequential, all amd_binary … s3 storage … DatabaseReplicated/ParallelReplicas variants, amd_debug … AsyncInsert/distributed plan … s3 storage, amd_debug sequential, amd_ubsan parallel/sequential, and Stress test (amd_debug) / (amd_ubsan).

Not PR-caused — sibling shards on the same binary passed cleanly:

• Stateless tests (amd_debug, parallel): Failed: 0, Passed: 7980, Skipped: 100
• Stateless tests (amd_asan, distributed plan, parallel, 2/2): Failed: 0, Passed: 3982, Skipped: 59
• Fast test: Failed: 0, Passed: 6958

This is the usual praktika runner flakiness. Next step: re-run the failed jobs.

4. DCO — process, not code

ACTION_REQUIRED: the merged upstream backport commits (Backport #… to 25.8, Merge pull request …) don't carry Signed-off-by for the committer. Expected on these bump PRs. Next step: maintainer sign-off / DCO override, as usual for release bumps — no code change.

---

Health check: the bump itself (version → 25.8.33, libssh 0.9.8 → 0.12.0 with the ML-KEM/config.h additions, plus the backported fixes) looks healthy — Fast test and the two stateless shards that actually ran are fully green. Nothing red is attributable to the bump's code. Actionable on this PR: re-run the infra-failed jobs, satisfy DCO, and (optionally) land the 04895 test-robustness tweak above.

---

I have not pushed anything. Want me to open a blau/* PR with the 04895 test fix (item 2), or commit it directly to bump/antalya-25.8/25.8.33? (Direct commit needs an explicit go-ahead per policy.)

_{— @blau-ai · evidence: run 33368943115, praktika result_pr.json, swarms job 99419352175}