[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):

Fixed wrong results of ORDER BY (unsorted rows, wrong rows under LIMIT) and the GroupingAggregatedTransform pushed bucket ... twice error (duplicated groups in older versions) of queries with parallel_replicas_mode = 'sampling_key', or a custom key mode on a cluster with more than one shard. Such a query now reads a shard from one replica unless the initiator only aggregates or fully sorts the parts returned by the replicas. (ClickHouse#128865 by @groeneai)

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: cherry-pick conflicts resolved by AI

Conflicted files:

• src/Processors/QueryPlan/Optimizations/Optimizations.h (both modified)
• src/Processors/QueryPlan/Optimizations/optimizeTree.cpp (both modified)
• src/Processors/QueryPlan/ReadFromRemote.cpp (both modified)
• src/Processors/QueryPlan/ReadFromRemote.h (both modified)

Commits:

• d0658d7: cherry-pick with the conflicts committed as-is

• 4625385: resolution

• Optimizations.h: master has a UseProjectionsResult return type that 26.8 lacks. I added the allowReadingShardsFromSeveralReplicas declaration and kept 26.8's std::optional<String> optimizeUseAggregateProjections( signature.

• optimizeTree.cpp: the incoming side also brought master's tryPushHavingPrefilterIntoAggregation pass, which 26.8 doesn't have. I dropped it and added only the final allowReadingShardsFromSeveralReplicas(root) call, after the group-by top-k pass.

• ReadFromRemote.cpp: I kept 26.8's comment wording, which still mentions parallel_replicas_only_with_analyzer, and added the && allow_reading_shard_from_several_replicas condition before GET_MANY is chosen. In initializePipeline I added the debug log and kept 26.8's addPipes(shards, output_header). Master's unavailable-shard tracker sealing is not included.

• ReadFromRemote.h: I kept 26.8's is_remote_function member and added the new allow_reading_shard_from_several_replicas = false member.

[github-actions]

Workflow [PR], commit [4625385]

[zvonand]

@blau-ai

[blau-ai]

CI triage for 4625385 (run 42066757212)

Summary: none of the test failures are caused by this PR. The only problem on the PR itself is DCO, and that's a sign-off issue, not code.

Check	Verdict
Integration tests (amd_asan_ubsan, db disk, old analyzer, 1/8, 5/8, 6/8, 7/8): 98 failures	Already failing on antalya-26.8 / test environment, not this PR
Regression release swarms: 3 scenarios	Already failing on antalya-26.8, not this PR
DCO	About this PR's commits: the upstream merge commit has no sign-off. Not a code problem
PR	Rollup check that goes red when anything above fails
RegressionTestsRelease Iceberg (2), S3Export (part)	Still running at the time of writing

The PR's own coverage is green. All stateless suites passed with 0 failures, for example amd_debug, parallel 13643 passed and amd_asan_ubsan, distributed plan, parallel, selected tests 77/77. No failure touches 05483_offset_parallel_replicas_ordered_merges or test_parallel_replicas_custom_key. The failing integration modules have nothing to do with parallel replicas, ReadFromRemote or the query-plan optimizations.

---

1. Integration tests (amd_asan_ubsan, db disk, old analyzer): 4 shards

Shard	Module	Failures
1/8	test_database_glue/test.py	37 (whole module, fails while the cluster starts)
5/8	test_storage_iceberg_with_spark/test_export_partition_iceberg.py	21
6/8	test_cas_gcs/test.py	37 (whole module, fails while the cluster starts)
7/8	test_backward_compatibility/test_custom_s3_disk_remote_url_allow_hosts.py (2), test_cas_gcs_relink_liveness/test.py (1)	3

What the errors say:

• glue / cas_gcs / relink_liveness / backward_compat: the mock or helper containers never start:

  Exception: Timed out while waiting for instance `sts.us-east-1.amazonaws.com' ... to start.
  bash: line 1: /usr/bin/clickhouse: cannot execute: required file not found
  

  The fakegcs and backward-compat node containers fail the same way. This is a problem with the test images or cluster setup; the server code under test never runs.
• iceberg export: every test fails on CREATE TABLE ... ENGINE=IcebergS3(s3, ...) with
  Code: 497 ... Not enough privileges ... necessary to have the grant SHOW NAMED COLLECTIONS SECRETS ON s3.
  That comes from the test setup and grants, not from parallel-replica logic.

Evidence that these come from the base branch: the same modules fail, with the same counts, on other open antalya-26.8 PRs that don't touch this code:

• Fix DataLakeCatalog table creation issues #2792: test_cas_gcs 37, test_export_partition_iceberg 21, test_custom_s3_disk_remote_url_allow_hosts 2+2
• 26.8 CAS avoid manifest get on promote #2794: test_export_partition_iceberg 21, test_custom_s3_disk_remote_url_allow_hosts 2
• CAS orphan sweep scheduling #2800: test_export_partition_iceberg 21, test_custom_s3_disk_remote_url_allow_hosts 2, test_cas_gcs_relink_liveness 1. Shard 1/8 there has the matching STS-mock failures (test_storage_s3/test_sts.py 7, test_datalake_glue_token_forwarding 3).

Next step: nothing to do on this PR. These need fixing on antalya-26.8: the mock-container image (/usr/bin/clickhouse not executable) and the missing named-collection grant in the iceberg export test.

2. Regression release swarms (report)

Failing scenarios:

• /swarms/feature/cluster discovery/check cluster discovery with wrong cluster name: expected exit code 33 but got Code: 279 ... Cannot connect to any replica for query execution. (ALL_CONNECTION_TRIES_FAILED)
• /swarms/feature/node failure/cpu overload and .../cpu overload all swarm nodes: Code: 209 ... Timeout exceeded while reading from socket ... receive timeout 300000 ms: While executing Remote. (SOCKET_TIMEOUT)

Evidence: #2792 and #2800 fail exactly these three scenarios, with the same ALL_CONNECTION_TRIES_FAILED lines, in their swarms reports. Already failing on antalya-26.8, not this PR.

3. DCO

d0658d7  Merge pull request #128865 from groeneai/offset-pa...   Sign-off not found
4625385  Resolve conflicts in backport of #128865                 Skipped: sign-off not required for members

The upstream merge commit that the backport brings in has no Signed-off-by. Other backport PRs bring in upstream merge commits the same way, so this is normally just marked as passing by a maintainer. Rebasing with --signoff would need a force-push, which I don't do. Getting it green is up to whoever manages DCO on this repo.

---

I didn't re-run anything locally. The test names and error lines come from the praktika result_pr.json and the swarms report, compared with #2792, #2794 and #2800. Iceberg (2) and S3Export (part) were still running, so check them once they finish.