Antalya 26.8: Do not reuse a server constant built in another scope.

[zvonand]

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

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

Fix UNION of a local query and cluster() (or another cluster function) throwing NUMBER_OF_COLUMNS_DOESNT_MATCH or THERE_IS_NO_COLUMN on GROUP BY hostName. A server constant built on the local branch was reused for the cluster branch and folded to the initiator value. Each scope now builds its own value, so shards report their own hostName, serverUUID, tcpPort, and the other server constants (#2471 by @ianton-ru).

CI/CD Options

Exclude tests:

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

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

Cherry-picked from #2471.

---

hostName captured Context::isDistributed from the first UNION branch and was then folded on a cluster branch, so the GROUP BY headers no longer matched.

Solved #1181

Documentation entry for user-facing changes

...

[github-actions]

Workflow [PR], commit [9951eed]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2515

Verdict: 0 PR-caused failures. All real test suites are green (builds, Fast test, every Stateless/Integration/Stress batch, AST fuzzer, BuzzHouse, SQLLogic/SQLStorm) — including this PR's new test 05294_union_hostname_with_cluster_function (passed in Stateless tests (amd_debug, parallel), Failed: 0). The four red checks are all pre-existing / infra / flaky and unrelated to the analyzer change.

The diff is tiny and well-scoped: a 6-line guard in src/Analyzer/Resolve/resolveFunction.cpp (!function->isServerConstant()) plus the new stateless test — nothing that touches builds, packaging, container images, or the swarm suite.

Per-failure breakdown

1. Parser memory check — ERROR → infra, not PR-related.
The failing sub-step is "Resolve master binary":

No master clickhouse-examples artifact was found

The job couldn't fetch the master-branch baseline binary it diffs against, so it errored before doing any parsing work (Failures: 1/2). This is a missing-baseline-artifact problem, independent of the diff. → Safe to re-run once a master clickhouse-examples artifact is available.

2. Regression {aarch64,release} swarms — 1 failing test → pre-existing/flaky, not PR-related.
Both arch reports show the same single underlying failure (the "3 scenarios" are just the parent nodes of one leaf): /swarms/.../check cluster discovery with wrong cluster name:

Code: 279. DB::Exception: ... Cannot connect to any replica for query execution. (ALL_CONNECTION_TRIES_FAILED)
(query: SELECT hostName(), count() FROM s3Cluster('swarm', ...) GROUP BY hostName() ...)

The test deliberately queries an undiscovered/"wrong" swarm cluster and asserts on the exit code; it's hitting a connection failure instead. I checked two unrelated open PRs against antalya-26.8 and both fail the exact same swarms test with the exact same error:

• Antalya 26.8: Added support for alter add column with first/after #2522 (ALTER add column) — swarms report
• Antalya 26.8: add UniqApacheHLL #2507 (UniqApacheHLL)

So this is an environmental/flaky failure in the swarm cluster-discovery suite on the branch, not a regression from #2515. (Note: the query happens to be exactly the hostName() + cluster shape this PR targets, but the failure mode is a connection error during discovery — not a wrong result or analyzer exception, and it reproduces on PRs that don't touch the analyzer.) → No action needed on this PR; track/fix in the swarms suite separately.

3. Grype Scan (keeper: 4 high/critical, server -alpine: 1 high/critical) — image CVEs, not PR-related.
These scan the built Docker images for known CVEs in OS/base-image packages. The non-alpine server image scanned clean (0). A C++ analyzer change cannot introduce or remove these; they're inherited from the base images and are consistent across the branch. → Address at the image/dependency level if desired; not a blocker for this change's correctness.

4. PR — aggregate gate reflecting the three items above; nothing of its own.

Health check

This is a clean cherry-pick of #2471: a minimal, targeted analyzer fix (don't reuse a server constant like hostName()/serverUUID() across scopes) with a dedicated regression test that passes. No functional, build, or integration regressions. The remaining red checks are baseline/infra (Parser memory check, Grype) and a known-flaky swarm test that fails identically on unrelated PRs. Nothing here requires a code change to #2515 — the swarms and Parser-memory jobs can be re-run / handled at the infra level.

Evidence: praktika report result_pr.json and swarms report.html for head 9951eed; comparison runs on #2522 and #2507.