Use Antalya protocol for Iceberg metadata instead of JSON

[ianton-ru]

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Use Antalya protocol for Iceberg metadata instead of JSON

Documentation entry for user-facing changes

...

Note for reviewer

JSON is still used with lock_object_storage_task_distribution_ms feature, I am planning to remove it later in separate PR.

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)

[ianton-ru]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-05T12:37:53.099848Z	401cda4	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

Workflow [PR], commit [6508b3b]

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 401cda414a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[zvonand]

lgtm, except for all the comments that explain obvious behavior a few times; that can be removed

[zvonand]

Pls trim the comment (at least starting with "It is not a...". no need to re-describe what is described above.

[zvonand]

same as above: I am sure we can remove those, otherwise this file will soon become overpolluted

[zvonand]

any reason we really need this comment?

[zvonand]

let's wait for CI and merge

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2482 @ 6508b3b

Verdict: 3 distinct failures (6 check rows) — 0 PR-caused. All are pre-existing / infra / known-flaky. Nothing here blocks on a code change in this PR; the functional suites are green (Fast test, Stateless ×all shards, Integration ×all shards, Stress, Unit, AST fuzzer, BuzzHouse, and every other Regression suite incl. iceberg_1/iceberg_2 all pass).

---

1–2. Grype Scan (keeper + server -alpine) — ❌ infra, not PR-caused

• GrypeScanKeeper / Grype Scan → 4 high/critical
• GrypeScanServer (-alpine) / Grype Scan → 1 high/critical

These are container base-image vulnerability scans (OS packages scanned against a CVE DB that updates daily). The flagged CVEs are all CVE-2025-* / CVE-2026-* OS-package issues, e.g. CVE-2026-85091, CVE-2026-84782/84784, CVE-2026-77696, CVE-2026-75804/75805/75806, CVE-2026-54872/54875.

This PR changes only src/** C++, docs/**, and one integration test — it touches no Dockerfile, no dependency, no packaging. Any PR built today produces the same scan result. → Not PR-caused; safe to ignore / re-run. (These Grype gates fail across antalya PRs generally; a human should bump the base image / accept the CVEs separately.)

3. Regression release s3_export_part — ❌ known-flaky, not PR-caused

Report: 1 module (1 failed), but only 1 of 90 scenarios actually failed:

/s3/minio/export tests/export part/concurrent alter — Fail (1h 28m)

Decisive error (server-side, during ALTER TABLE … FETCH PARTITION in alter_wrappers.py:418 alter_table_fetch_partition):

Code: 1001. DB::Exception: Received from localhost:9000. DB::Exception:
std::__1::filesystem::filesystem_error: filesystem error: in rename:
No such file or directory. (STD_EXCEPTION)

This is a local-filesystem race during concurrent ALTER on MergeTree parts — a code path this PR does not touch. The PR is purely about the Iceberg/cluster-function read-task protocol (ClusterFunctionReadTask, StorageObjectStorageCluster, StorageObjectStorageStableTaskDistributor, TCPHandler, Connection, AntalyaProtocol.h); the one IObjectStorage.cpp hunk is just a comment + moving column-stats into the protocol trailer. No rename / FETCH PARTITION / MergeTree logic is modified (git diff keyword scan for rename|fetch|filesystem|MergeTree|export hits only a doc line).

The export part / concurrent alter scenario is a known pre-existing flaky/race bug, tracked by #1189 and #1190 ("Seg faults and logical errors when detaching/attaching partitions with ongoing exports"), which explicitly says "Reproduction can be flaky… related to race conditions" and reproduces via --only "/s3/minio/part 3/export part/concurrent alter/*". → Not PR-caused; re-run. If it keeps reproducing, fold it into #1190 rather than this PR.

---

Health check

The PR looks healthy: all functional, integration, stress, unit, fuzzer, and regression suites (including the directly-relevant iceberg_1/iceberg_2 and the new test_iceberg_mixed_antalya_upstream integration test) pass. The only reds are a daily base-image CVE gate and one known-flaky concurrency scenario — neither related to the Antalya-protocol metadata change. I'd re-run the s3_export_part job; no code change is needed for CI on this PR.

(Automated triage — I can't build/run ClickHouse in this container, so classifications are from the praktika S3 reports + the diff. Correctness of the PR itself is validated by the green suites above.)