stable-25.8: parallel replicas returns wrong count with additional_table_filters + minmax_count projection (flaky 01710_projection_additional_filters)

[CarlosFelipeOR]

Type of problem

Bug report - something's broken

Describe the situation

01710_projection_additional_filters is flaky on stable-25.8 in the ParallelReplicas config (6 fails / 14 OKs; 0 fails in all other configs). When it fails, count() returns more rows than exist:

select count() from atf_p settings additional_table_filters = {'atf_p': 'x <= 2'};   -- table has 10 rows (0..9)
-- expected 3, got 23

Under parallel replicas the minmax_count_projection path returns an unfiltered count that gets summed with the correctly-filtered count (23 = unfiltered + filtered), so additional_table_filters produces wrong aggregates. This is a genuine data-correctness bug, not just a test artifact.

Not Altinity-specific. The test is identical to 25.8.24 (unchanged), and the same flakiness exists on upstream master (44 fails / 3282 OKs). Upstream diagnosed it (same unfiltered + filtered pattern) in ClickHouse#104219 and fixed it in ClickHouse#104296 2026-05-20). That fix is not on the 25.8 line: the direct backport to upstream 25.8 (ClickHouse#105421) was closed, and upstream only stabilized the 04201 test (ClickHouse#108904, already present here) without taking the code fix. So the correctness fix is absent in both upstream 25.8 and Altinity stable-25.8. Began surfacing on Altinity at the 25.8.28 bump (PR #2024, 2026-07-10); upstream 25.8 CI does not run the ParallelReplicas stateless config, so it stays latent there.

How to reproduce

• Branch: stable-25.8 (25.8.28)
• Run: MasterCI — Stateless (amd_binary, ParallelReplicas, s3 storage, parallel)
• Intermittent — requires the ParallelReplicas path with the minmax_count projection.

Expected behavior

count() with additional_table_filters returns the filtered count (3).

Actual behavior

Returns unfiltered+filtered sum (23, 13, ...), intermittently.

Suggested fix

1. Backport upstream ClickHouse#104296 ("Disable additional_table_filters with parallel replicas and analyzer and w/o query plan serialization") — the real correctness fix. Small (src/Planner/Planner.cpp +22, plus 04201/04207 test refs) and feasible (serialize_query_plan setting exists on 25.8). Note: upstream deliberately did not backport it to 25.8, so this is an Altinity-specific divergence, and it conflicts with the 04201 stabilization already in the branch.
2. Mark the test as broken for the ParallelReplicas config in tests/broken_tests.yaml (applied as the interim mitigation, referencing this issue) so CI is not blocked by the flaky wrong-result while the backport decision is made.

[CarlosFelipeOR]

This bug is present on upstream 25.8 as well, and upstream deliberately did not backport the fix there: the direct backport of ClickHouse#104296 to 25.8 (ClickHouse#105421) was closed, and they only stabilized the 04201 test (ClickHouse#108904, already in our branch) without taking the code fix.

I also attempted a manual cherry-pick of ClickHouse#104296 and it isn't clean on 25.8 — the new test 04207_pr_additional_filters uses settings that don't exist on this version (automatic_parallel_replicas_mode, query_plan_remove_unused_columns), and its EXPLAIN PLAN reference would need regenerating.

So for now I'm marking 01710_projection_additional_filters as broken for the ParallelReplicas config in #2050, referencing this issue. The full backport of ClickHouse#104296 remains the proper fix and is tracked here.