[zvonand]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

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

...

Documentation entry for user-facing changes

...

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)

[zvonand]

Backporter: merge conflicts resolved by AI

Conflicted files:

• cmake/autogenerated_versions.txt (both modified)
• src/Disks/DiskObjectStorage/ObjectStorages/S3/diskSettings.cpp (both modified)

Commits:

• 6cdf0e0: merge with the conflicts committed as-is

• fb7f610: resolution

• cmake/autogenerated_versions.txt: both sides changed the patch, git hash and version strings. I used upstream's patch 60 and git hash, with Altinity's naming: v26.3.60.20001.altinityantalya / 26.3.60.20001.altinityantalya.

• src/Disks/DiskObjectStorage/ObjectStorages/S3/diskSettings.cpp: upstream added a header-filter check for the gcp_oauth HTTP client in getClient, in the same place where Altinity has its S3::ClientCacheRegistry shared_cache lookup.

• I kept both, with the gcp_oauth check first and then the shared_cache lookup, which the ClientFactory::create call still uses. Upstream's new includes merged cleanly.

[github-actions]

Workflow [PR], commit [70b85f0]

[mkmkme]

@blau-ai the build has failed here:

/ClickHouse/src/Databases/DataLake/RestCatalog.cpp:1111:81: error: use of undeclared identifier 'headers'
 1111 |     context->getGlobalContext()->getHTTPHeaderFilter().checkAndNormalizeHeaders(headers);
      |                                                                                 ^~~~~~~
1 error generated.

Seems like the conflict resolution wasn't so clean there. Fix it and commit to this PR

[blau-ai]

Fixed in 70b85f064ca (pushed to bump/antalya-26.3/26.3.60).

Cause: the conflict resolution in RestCatalog::sendRequest moved the header-normalization call above the headers declaration, so it referenced a variable that didn't exist yet:

const auto & context = getContext();
context->getGlobalContext()->getHTTPHeaderFilter().checkAndNormalizeHeaders(headers); // <-- headers not declared yet
...
DB::HTTPHeaderEntries headers = getAuthHeaders(...);  // actual declaration

Fix: moved the checkAndNormalizeHeaders(headers) call to right after headers is built and before it's passed to .withHeaders(headers) — matching the existing pattern in the GET path of the same file (getAuthHeaders → checkAndNormalizeHeaders → withHeaders). The context line stays where it was since it's still used below for read settings / timeouts / host filter.

     const auto & context = getContext();
-    context->getGlobalContext()->getHTTPHeaderFilter().checkAndNormalizeHeaders(headers);
 ...
     DB::HTTPHeaderEntries headers = getAuthHeaders(/* update_token = */ true, method, url, extra_headers, body_str);
     headers.emplace_back("Content-Type", "application/json");
+    context->getGlobalContext()->getHTTPHeaderFilter().checkAndNormalizeHeaders(headers);
     auto wb = DB::BuilderRWBufferFromHTTP(url)

That was the only error in the build log (1 error generated), and there are no leftover conflict markers in the file. CI on this PR will confirm the compile.

[zvonand]

The integration tests were not run -- why? @blau-ai

[zvonand]

@blau-ai

[blau-ai]

CI triage for 70b85f0

5 failing checks. None are caused by this PR. 3 are infra (DNS/network hangs on the runners), 1 is a known flaky Swarms scenario, and 1 is DCO, which isn't a test.

Check	What failed	Verdict
Stateless (amd_debug, sequential)	03271_s3_table_function_asterisk_glob, 02789_filesystem_cache_alignment, 00157_cache_dictionary, plus "Some queries hung"	Infra: DNS hang
Stateless (amd_debug, distributed plan, s3 storage, sequential)	03271_s3_table_function_asterisk_glob, 02789_filesystem_cache_alignment	Infra: DNS hang (same pattern)
Stateless (amd_ubsan, parallel)	0 tests failed; only "Some queries hung" (the 10 BROKEN are known entries in broken_tests.yaml)	Infra: DNS hang
RegressionTestsRelease / Swarms	/swarms/feature/node failure/check restart swarm node	Known flaky, already seen on other PRs
DCO	Commits missing Signed-off-by	Process/sign-off issue, not code

PR is only the aggregate gate. The tsan, msan and arm jobs show "skipping" because this workflow excludes those tags (Skipped, job name includes excluded tag ...). They didn't fail.

---

1–3. Stateless suites: queries stuck in getaddrinfo while reading external data

Every hung query is waiting on a DNS lookup for an external HTTPS host. Two cases:

• Datasets read through the web disk (test.hits).
• s3('https://clickhouse-public-datasets.s3.amazonaws.com/...').

amd_ubsan, from the hung-check processlist:

elapsed:  721.018406
query:    INSERT INTO hits_buffer SELECT * FROM test.hits WHERE CounterID = 800784;
stacktraces: ... __GI___poll
  __res_context_send / _nss_dns_gethostbyname4_r / getaddrinfo
  Poco::Net::DNS::hostByName  (DNS.cpp:80)
  ... SecureSocketImpl::connectSSL ... HTTPConnectionPool.cpp:579 prepareNewConnection
  ... ReadWriteBufferFromHTTP ... DB::ReadBufferFromWebServer::nextImpl

amd_debug, sequential (hung check fired twice, both times the same query):

elapsed:  809.785381 / 1067.701101
query:    INSERT INTO test.hits_1m SELECT * FROM test.hits LIMIT 1000000
  ... getaddrinfo ... DB::ReadBufferFromWebServer::nextImpl()

03271_s3_table_function_asterisk_glob failed in both debug jobs with the same error:

Timeout exceeded while receiving data from server. Waited for 300 seconds
(query: SELECT * FROM s3('https://clickhouse-public-datasets.s3.amazonaws.com/wikistat/original/*', NOSIGN) LIMIT 1 ...)

02789_filesystem_cache_alignment and 00157_cache_dictionary hit the test timeout in the same jobs. The test runs one at a time in sequential mode, so once the server is stuck on these lookups the tests behind them time out too.

Why this isn't the PR:

• The bump doesn't touch DNS, SecureSocketImpl or HTTPConnectionPool. Its HTTP-related changes are a CR/LF check in HTTPRequest::write and GCP OAuth / S3 request validation. Neither is anywhere near a resolver hang.
• Other PRs on the same base fail on the same kind of remote-dataset tests (00172_hits_joins, 04033_tpc_ds_*, 00152_insert_different_granularity, 00071_merge_tree_optimize_aio):
  • Antalya 26.3 Backport of #102156 - Fix Nullable(X)->Y cross-type ALTER MODIFY COLUMN #2712 (a small ALTER fix): 13 such failures in amd_debug parallel.
  • Antalya 26.3 - CI parity from 26.8 #2724 (CI parity): 23 such failures in arm_binary parallel.
• In the ubsan job, 03441_deltalake_clickhouse_public_datasets and 03441_deltalake_clickhouse_virtual_columns were marked BROKEN with INVESTIGATE - S3 sometimes unreachable. The same network symptom is already tracked there.

Next step: safe to re-run. If these keep showing up on every PR, look at DNS resolution on the stateless runners. That's an infra fix, not a change for this PR.

4. RegressionTestsRelease / Swarms: node failure/check restart swarm node

✘ [ Fail ] '/swarms/feature/node failure/check restart swarm node' (1m 50s)
  File ".../swarms/tests/node_failure.py", line 108, in run_long_query
    assert result.exitcode in expected_exitcodes, ...
1535 scenarios (1520 ok, 1 failed, 14 skipped)

This test restarts a swarm node while a long query is running, then checks the query's exit code against an allow-list. The report doesn't print the actual exit code. The same scenario failed earlier:

• on Antalya 26.3 Backport of #107059 - Fix NOT_FOUND_COLUMN_IN_BLOCK in the native Parquet V3 reader prewhere handling #2624 (same antalya-26.3 base, Parquet-only change);
• on Antalya 26.8: Iceberg: reuse the Puffin object metadata across deletion-vector reads #2665 (antalya-26.8), where it also failed at the baseline commit without that PR's changes.

It passed on #2724 and #2654. Nothing in this bump touches swarm or cluster task distribution. Known flaky, safe to re-run.

5. DCO

Status is action_required. Some of the 79 commits (mostly upstream ones brought in by the version bump) have no Signed-off-by. Backport PRs on the same base fail DCO the same way (#2712, #2697). Nothing to fix in the code: a maintainer can override DCO in the app, or merge as usual if DCO isn't a required check.

---

Bottom line: I found no failures caused by the 26.3.60 bump, so I suggest no code changes. Re-running the three stateless jobs and Swarms should be enough. If a re-run fails on a test that doesn't read remote data, ping me again.