Antalya 26.3: Bump to v26.3.53.4

[mkmkme]

In addition, ClickHouse#125569 was backported as well as in #2589

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 [d7f87ae]

[mkmkme]

Backported ClickHouse#110757, which is a 26.4 backport of ClickHouse#100849. Here's the Codex summary of the reason:

The Protobuf recovery tests fail consistently in ASan and UBSan because 26.3 caches schema importers only by directory and reuses descriptors by message name. Different schemas defining Row therefore receive the first schema’s descriptor. This is a production cache bug, not a sanitizer or merge-resolution issue.

Decision: backport upstream PR ClickHouse#100849, including the cache-key fix, ProtobufList fallback, documentation, and upstream regression tests. This fixes the underlying behavior rather than masking it by clearing the cache in tests.

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2595 (Antalya 26.3 → v26.3.53.4 bump)

Verdict: Builds, unit tests, fast test, stress tests and fuzzers are all green. The red checks split into PR‑caused (6 groups — all a consequence of the version bump, and all fixable here) and not‑PR‑caused (4 — infra/flaky/process noise, safe to re‑run or ignore).

The bump pulls in upstream backport ClickHouse#123133 "Require permission to override named collections" (commit 435fc71), which removes the old allow_named_collection_override_by_default=true default. From now on, touching a named collection requires the SHOW NAMED COLLECTIONS SECRETS / NAMED COLLECTION grants. Upstream added those grants to its own test users.xml files, but the Antalya‑specific tests weren't covered — that explains most of the integration failures. Three backported object‑storage stateless tests also fail consistently.

---

🔴 PR‑caused (fix in this PR)

1. test_storage_iceberg_with_spark/test_export_partition_iceberg.py — 42 failures (suites 5/5, 6/8)
Code: 497 … necessary to have the grant SHOW NAMED COLLECTIONS SECRETS ON s3.
The grant file configs/users.d/users.xml already carries both flags, but the cluster nodes load only configs/users.d/allow_export_partition.xml (which grants nothing). Fix — add the grant file to every node's user_configs:

            user_configs=[
                "configs/users.d/allow_export_partition.xml",
                "configs/users.d/users.xml",
            ],

(both the node1 block and the replica1/2/3 loop, ~lines 87 and 102).

2. test_storage_iceberg_multistorage/test.py — 18 failures (suites 5/5, 8/8)
Same Code: 497. Here configs/users.d/users.xml is loaded but is missing one flag. Fix:

             <named_collection_control>1</named_collection_control>
+            <show_named_collections_secrets>1</show_named_collections_secrets>

3. test_mask_sensitive_info/test.py — 8 failures (suites 4/5, 8/8) — ⚠️ security‑relevant
This is not a grant problem (its users.xml is correctly wired). It's a secret‑masking regression for the iceberg table functions:

• test_iceberg_cluster_function: assert not contains_in_log('Eby8vdM0…==') fails → the raw S3/Azure key is leaking unmasked into the server log for icebergCluster(...).
• test_create_table / test_table_functions_object_storage_cluster / test_backup_table_azure_named_collection: the expected [HIDDEN]‑masked form isn't in the log.

The bump changed credential masking (see backport ClickHouse#122770), and Antalya's iceberg/icebergCluster functions appear to be outside the masking list. This one needs a code look (extend the function‑argument masking to cover the iceberg*/*Cluster functions), not just a test tweak — please don't wave it through as a flaky test, a real secret is hitting the logs.

4. 03363_hive_style_partition (stateless, debug/ubsan/asan‑s3‑seq) — introduced by backport ClickHouse#111842 (22f468e)

Code: 117. A hive partitioned file can't contain only partition columns…
(query: CREATE TABLE … engine=S3(…) SETTINGS use_hive_partitioning=1;)

The test comment says "sample path is resolved lazily, so CREATE succeeds and the first use fails", but the error fires eagerly at CREATE. The ClickHouse#111842 "resolve hive partitioning sample path lazily" change doesn't take effect on Antalya's object‑storage path — likely a merge/rebase gap between the backport and Antalya's divergent storage code.

5. 05292_iceberg_malformed_manifest_list_writer (stateless, parallel asan/debug/ubsan) — introduced by backport ClickHouse#122829 (a6f4c25)

Code: 481. File URI '…/snap-…avro' is outside of allowed `user_files` path ''. (PATH_ACCESS_DENIED)

The test launches clickhouse-local … -- --user_files_path=<dir>, but the server reports the allowed path as empty — the --user_files_path passed after -- isn't being honored, so the INSERT INTO FUNCTION file('<abs path>') is rejected. Needs a check of how Antalya's clickhouse-local parses args after --.

6. 04627_object_storage_lazy_hive_partitioning (stateless, parallel) + "Some queries hung" — also from backport ClickHouse#111842
Fails with a cleanup TimeoutError (_cleanup_database), and the suites report the companion "Some queries hung" failure — a query from this test doesn't terminate. Same lazy‑hive‑partitioning backport as #4; the hang is almost certainly the same root cause.

All six are genuinely reproducible (identical across asan/debug/ubsan) and all six touch files that this PR's backports added/modified, so none are pre‑existing on antalya-26.3.

---

🟡 Not PR‑caused (re‑run / ignore)

• Integration tests (amd_asan, db disk, old analyzer, 6/8) → test_s3_cluster (27) — infra/flaky. All 27 are the one module fixture failing: instance s0_0_1 didn't open port 9000 before the timeout. Its clickhouse-server.log shows no <Fatal>, no LOGICAL_ERROR, no sanitizer report — the server just started slowly (asan + "db disk" is heavy). Safe to re‑run.
• SQLLogic test → Timeout (3h01m). Whole‑job wall‑clock timeout, unrelated to the backports. Re‑run; if it times out again it's a runner‑capacity issue, not this PR.
• Grype Scan (keeper / server / server‑alpine, 3 checks) — each reports "Completed with 0 high/critical vulnerabilities". No blocking CVEs from this PR's code; this is base‑image/dependency scan policy noise.
• DCO — process gate (failed in 1s). A 990‑commit rebase of upstream robot/merge commits will trip DCO sign‑off; needs a maintainer override, not a code change.
• Aggregate gates (PR, FinishCIReport, Finish Workflow) just reflect the above and will clear once the real failures are resolved.

---

Suggested next steps

1. Apply the grant fixes Update README.md #1 and Update README.md #2 (pure test‑config, low risk).
2. Triage Update README.md #3 as a masking code fix (secret leak) — highest priority.
3. Look at Update README.md #4/Update README.md #5/Update README.md #6 together: the Resolve hive partitioning sample path lazily ClickHouse/ClickHouse#111842 (lazy hive partition) and Fix crash on invalid Iceberg manifest-list entries ClickHouse/ClickHouse#122829 (iceberg manifest / clickhouse-local --user_files_path) backports need reconciling with Antalya's object‑storage divergence.
4. Re‑run test_s3_cluster and SQLLogic; handle DCO/Grype as release‑process gates.

I can open a blau/* PR with the two grant‑config fixes (#1, #2) right away if you'd like — just say the word (or tell me to commit them directly onto rebase/antalya-26.3/26.3.53). The rest I'd leave to you since they need code/behaviour decisions.

_{Evidence: praktika result_pr.json + job.log for sha 3557eae. I can't build/run ClickHouse in this container, so correctness of any fix would be confirmed by CI on the follow‑up.}

[zvonand]

@blau-ai fix PR-caused test fails (#2595 (comment)) directly in this branch

[blau-ai]

Done — committed the two confidently-fixable, test-config failures directly onto rebase/antalya-26.3/26.3.53 as you asked: 9cff1b4d80f.

✅ Fixed in this commit

#1 test_storage_iceberg_with_spark/test_export_partition_iceberg.py — the cluster nodes loaded only configs/users.d/allow_export_partition.xml (grants nothing), so every node hit Code: 497 … SHOW NAMED COLLECTIONS SECRETS. Added the existing configs/users.d/users.xml (which already carries named_collection_control + show_named_collections_secrets) to both the node1 and the replica1/2/3 user_configs.

#2 test_storage_iceberg_multistorage/test.py — its users.xml had named_collection_control but was missing show_named_collections_secrets; added it.

Both are pure test-config, so I'm confident in them — but as always for this container, correctness is validated by CI on this PR, not locally (I can't build/run the server here).

⚠️ The other four I did not touch — here's why, with new static evidence

I dug into #3–#6 in the worktree and they are not the clean one-line fixes my first triage implied. Committing unverifiable guesses here (especially into a release branch) would risk making things worse, so I'm reporting instead:

• Update README.md #3 test_mask_sensitive_info (secret masking) — my earlier "missing from the masking list" hypothesis was wrong. The masking code in src/Parsers/FunctionSecretArgumentsFinder.cpp already handles all the functions the test exercises — iceberg/icebergCluster (added by this very bump, commit 071d6ada), icebergS3/icebergS3Cluster, icebergAzure/icebergAzureCluster. So the list is complete and editing it would be a wrong fix. The failure (raw key in log / missing [HIDDEN] form) must come from a runtime divergence — e.g. Antalya's icebergS3Cluster/icebergAzureCluster resolving/parsing differently, or the leak coming from a different log path — which I can't pin down or verify without a build+run.

• Update README.md #4 03363_hive_style_partition / Update README.md #6 04627_object_storage_lazy_hive_partitioning (backport Resolve hive partitioning sample path lazily ClickHouse/ClickHouse#111842). The lazy-resolution machinery is present in StorageObjectStorage.cpp (hive_partitioning_sample_path_deferred, resolveHivePartitioningIfNeeded, the need_resolve_sample_path gating). So this isn't a trivially-dropped hunk; figuring out why it still fires eagerly on Antalya's object-storage path (and why Update README.md #6 hangs) needs reconciling the backport against Antalya's divergent storage code and a build to confirm.

• Update README.md #5 05292_iceberg_malformed_manifest_list_writer (backport Fix crash on invalid Iceberg manifest-list entries ClickHouse/ClickHouse#122829). clickhouse-local … -- --user_files_path=<dir> arg-parsing — purely a runtime/CLI behaviour question; no way to confirm a fix statically.

Suggested path for #3–#6

These need someone who can build/run: #3 is the priority (real secret-in-log), then #4/#6 together (same ClickHouse#111842 backport), then #5. Happy to go deeper on any one of them — e.g. pull the clickhouse-server.log for the mask test and trace the exact unmasked line — if you want me to keep digging; just point me at it.

_{Config fixes reasoned from the test fixtures + CI result_pr.json for 3557eae. I can't build/run ClickHouse in this container, so CI on this branch is the validation.}

[zvonand]

@blau-ai

[blau-ai]

Sorry, I couldn't finish this task (job 225: claude exited with 1: turns=4 cost=$10.11 result=error_max_budget_usd). Please mention me again to retry.

[zvonand]

@blau-ai

[blau-ai]

CI triage for d7f87ae

Verdict: 0 failures are caused by this PR. Everything that actually ran is green; the red checks are one Docker-registry infra flake (plus its cascade) and two pre-existing repo-wide gates (DCO sign-off, Grype).

Check	Class	PR-caused?
Stateless tests (amd_debug, parallel)	Infra flake (Docker Hub TLS timeout)	❌ No
PR / FinishCIReport	Cascade of the above	❌ No
DCO	Pre-existing (backport commits w/o sign-off)	❌ No
GrypeScan Server / Server-alpine / Keeper	Pre-existing gate (also red on base branch)	❌ No

1. Stateless tests (amd_debug, parallel) — infra flake

The job never started the tests; it died pulling the test image:

ERROR: Job killed, exit code [125]
Unable to find image 'altinityinfra/stateless-test:48a9040a5c12e6e1bcc4_amd' locally
docker: Error response from daemon: Get "https://registry-1.docker.io/v2/altinityinfra/stateless-test/manifests/sha256:...":
        net/http: TLS handshake timeout.

This is a Docker Hub registry TLS-handshake timeout — pure infra, unrelated to the diff.
Next step: re-run this job.

2. PR + FinishCIReport — cascade only

The praktika runner dropped every downstream job after the error above; each dropped entry in result_pr.json reads literally Dropped due to previous failure [Stateless tests (amd_debug, parallel)] (all the integration/stress/stateless/compat/install jobs, SQLLogic, AST fuzzer, BuzzHouse). The PR and FinishCIReport aggregate gates are red solely because of that cascade. Re-running (1) should clear them.

3. DCO — pre-existing, not fixable from this PR

The DCO app reports "There are 140 commits incorrectly signed off." These are upstream/backport commits (Backport #… to 26.3: …, Disable croaring AVX-512 …, etc.) that carry no Signed-off-by trailer — inherent to a rebase/version-bump branch. Fixing it would require rewriting history across 140 commits (force-push), which I won't do and which isn't desirable here. This is the usual state for bump PRs and is cleared by a maintainer admin-merge / DCO override, not by a code change.

4. Grype scans — pre-existing repo-wide gate

All three (GrypeScanServer, GrypeScanServer (-alpine), GrypeScanKeeper) report failure while the status text says "Grype Scan Completed with 0 high/critical vulnerabilities." The identical three checks are also failing on the base branch antalya-26.3 HEAD (162b313), so this is a standing gate state, not something this PR introduced. Grype scans the built Docker images (OS packages); a version bump doesn't change that surface relative to the base branch.

What actually ran — all green

• Fast test: 0 failed / 8277 passed
• Builds (amd debug/asan/ubsan/binary/release, arm release): 0 failures
• Stateless tests (amd_asan, distributed plan, parallel 1–4/4): 0 failed (~9670 passed)
• Integration tests (amd_asan, targeted): 0 / 220
• Unit tests (asan): 0 fail / 11075; Unit tests (ubsan): 0 fail / 11078
• AST fuzzer (targeted): ok; Docker server/keeper images: ok; Source upload: ok

Recommendation

1. Re-run "Stateless tests (amd_debug, parallel)" (or re-trigger the PR workflow) to clear the infra flake and run the dropped suites.
2. DCO + Grype are pre-existing gate states, not code problems — they need a maintainer override / admin-merge as is standard for these bump PRs.

No code change is warranted from this triage, so I haven't opened anything.

_{🤖 automated CI triage by @blau-ai · evidence: result_pr.json, DCO check-run 117978335380, base-branch 162b313 statuses}