Stable 26.3: Bump to 26.3.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 [81da36d]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2357 (bump to 26.3.33)

Verdict — 6 red buckets: 0 caused by the upstream 26.3.33 content, but 3 are real blockers that live in Altinity-fork code. Two are pre-existing fork bugs (one of them newly caught by a test the bump imported), one is a non-idempotent test, plus the usual DCO + regression-flake noise. Nothing here is a defect in the 26.3.33 changes themselves — every failing product path (FunctionsAES, plain-rewritable metadata, the AES fast path) is byte-identical to stable-26.3 or is exercised by a newly-added test.

Head SHA: f82b79b. Evidence is from the praktika result_pr.json and the S3 job logs.

---

1. Unit tests (asan) + (ubsan) — 🔴 real crash, blocks this PR (latent fork bug, newly caught)

Both jobs error with no gtest.json. The asan .log aborts on:

src/Disks/tests/gtest_disk_object_storage.cpp  ->  DiskObjectStorageTest.CopyEmptyFileToPlainRewritable
Skipping writing empty blob for path CopyEmptyFileToPlainRewritable_file, key ...
contrib/llvm-project/libcxx/include/__vector/vector.h:429: libc++ Hardening assertion !empty() failed: front() called on an empty vector

Root cause (I traced it):

• The test (copy a 0-byte file to a plain_rewritable disk) is new — it does not exist on stable-26.3; it arrived with the 26.3.33 bump.
• Because the plain-rewritable metadata storage reports supportsEmptyFilesWithoutBlobs() == true, DiskObjectStorageTransaction.cpp:350-351 takes the "skip empty blob" branch and calls tx->createMetadataFile(path, /*objects=*/{}) with an empty list.
• MetadataStorageFromPlainRewritableObjectStorage.cpp:410 then does objects.front() unconditionally → front() on empty vector → abort.

The objects.front() code and the empty-blob-skip both already exist on stable-26.3, so this is a pre-existing latent bug in the fork's plain-rewritable path that the newly-imported upstream test simply exposes. It still has to be fixed for this PR to go green.

Concrete fix (pick one):

• In MetadataStorageFromPlainRewritableObjectStorageTransaction::createMetadataFile (.../MetadataStorages/PlainRewritable/MetadataStorageFromPlainRewritableObjectStorage.cpp:406-415), handle the empty-objects case instead of calling objects.front() (create a zero-blob metadata entry), or
• have the plain-rewritable metadata storage return supportsEmptyFilesWithoutBlobs() == false (it doesn't actually support blob-less empty files given the .front() assumption), so the transaction writes a real empty blob.

The first is preferable — it keeps the empty-files-without-blobs optimization. This needs someone familiar with the Antalya plain-rewritable design.

---

2. Stateless tests — amd_debug / amd_ubsan / amd_asan(dist plan 3/4) / amd_debug(s3) — 🔴 real, but pre-existing, NOT caused by this bump

All four shards fail on the same test, 04337_encrypt_decrypt_block_modes (result differs with reference). The actual output balloons from 104 to ~1630 rows with ciphertext that accumulates across rows (row N contains row N-1's blocks) — a genuine state-leak in the AES ECB/CBC fast path.

Why it's not this PR's doing:

• src/Functions/FunctionsAES.h has an identical blob SHA on stable-26.3 and on this PR's head (a4e9ec0…). No AES/encrypt/decrypt source is touched by the PR.
• The test file is also unchanged and already exists on stable-26.3 (3602b9b…).

Same code + same test ⇒ it fails identically on the base branch. This is a pre-existing bug in the fork's AES fast-path optimization (the test was added by Altinity precisely to guard it, per the header comment referencing ClickHouse#65116). Recommend filing a separate issue against stable-26.3; it should not block the bump, but it is a real correctness bug worth fixing on its own.

---

3. Integration tests (amd_asan, targeted) — 9/460 — 🟡 non-idempotent test, not a product regression

All 9 failures are the same test under CI's 10× repeat: test_lost_part_during_startup[1-10] … [10-10] (only one repetition passes). Error:

Code: 57. DB::Exception: Table default.test_lost already exists. (TABLE_ALREADY_EXISTS)
(query: CREATE TABLE test_lost ... ReplicatedMergeTree('/clickhouse/test_lost', '1') ...)

tests/integration/test_lost_part_during_startup/test.py creates a fixed table name + fixed ZK path and never drops it. When the targeted job runs it 10× against the same module cluster, repetitions 2..10 collide. The test file is unchanged by this PR — this is a pre-existing test-isolation defect that only shows up under the repeat harness.

Concrete fix: add DROP TABLE IF EXISTS test_lost SYNC on both nodes at the start of the test (and/or a teardown fixture), or make the table name/ZK path unique per run. Safe to treat as noise for the bump; the fix is a one-liner in the test.

---

4. DCO — 🟡 expected for a bump PR

Merge/bump PR carrying ~100 upstream commits without Signed-off-by for the bumper. Standard for these branches — a maintainer override/waiver, not a code change.

---

5. Regression release parquet / parquet_aws_s3 — 🟡 likely flaky, re-run to confirm

Both report the top-level /parquet module failing with retries that partially recovered (5 retries: 3 ok, 2 failed). That retry-mixed pattern is the signature of instability in the TestFlows Parquet suite rather than a hard regression. I could not pin the specific failing scenario from the --log-failed output (only the top-level ✘ [ Fail ] '/parquet' is surfaced). Suggested next step: re-run the two regression jobs; if they reproduce, open the parquet report to find the failing sub-test.

---

6. "PR" check — aggregate gate, red only because of the above.

---

What to do

• Blocker for merge: Update README.md #1 (unit-test crash) — needs the plain-rewritable createMetadataFile / supportsEmptyFilesWithoutBlobs fix above.
• Pre-existing, file separately, shouldn't block the bump: Update README.md #2 (AES fast-path correctness on stable-26.3).
• Trivial test fix, noise for the bump: Update README.md #3 (DROP TABLE IF EXISTS … SYNC).
• Re-run: Update README.md #5 (regression parquet) to confirm flakiness.
• Maintainer action: Update README.md #4 (DCO waiver).

I can prepare the #1 and #3 fixes as a blau/* PR (or, if you'd rather, as a direct commit to bump/stable-26.3/26.3.33) — say the word and which delivery you prefer. I did not push anything. Note: I can't build/run ClickHouse here, so any fix would be validated by CI on the resulting PR.

_{🤖 automated CI triage by @blau-ai · code/log excerpts are evidence, not verified locally}