Antalya 25.8 Backport of #95597 - Fix zero‑copy unlock check before part dir move

[mkmkme]

25.8.16 Backport of ClickHouse#95597 - Fix zero‑copy unlock check before part dir move

Same as #1738, but for Antalya 25.8

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 regression in (experimental) zero‑copy replication introduced by ClickHouse#94262 where shared parts could be deleted before other replicas finished fetching them (ClickHouse#95597 by @filimonov).

Documentation entry for user-facing changes

...

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful 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)
• 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 [93b8728]

[mkmkme]

@blau-ai

[blau-ai]

CI triage — 3 red checks, 0 caused by this PR

Verdict: 2 real failures + 1 aggregate gate → 0 PR-caused, 1 infra kill, 1 unrelated flake. This PR only reorders the can_remove_callback() evaluation in DataPartStorageOnDiskBase::remove() (zero-copy part-dir move). Neither failing job touches that path. Both are safe to re-run.

---

1. Build (amd_release) — ❌ infra kill, not PR-caused

Status text: "Job got terminated with an error, exit code [-15]" (job).

The compile + link actually finished successfully before the kill:

[15529/15531] Stripping clickhouse binary
[15531/15531] ... compressor clickhouse ../clickhouse
[0/1] Install the project...
ERROR: Run failed with exit code [-15]     # SIGTERM, ~2h13m in, during post-build finalization

So the code built and linked 100% (15531/15531) and was installed; the runner was then terminated with SIGTERM during the packaging/upload phase. This is a runner/infra termination, not a compile error from the diff. (An early command failed … retry 0/1 during checkout also points at flaky infra.)
→ Next step: re-run Build (amd_release). The amd_binary / amd_debug builds and the asan AST-fuzzer all built fine from the same commit.

2. Stateless tests (amd_binary, ParallelReplicas, s3 storage, parallel) — ❌ 1 flaky test, not PR-caused

Failed: 1, Passed: 7112, Skipped: 751, Broken: 2. The one failure:

01710_projection_additional_filters: [ FAIL ] — result differs with reference
@@ -1,2 +1,2 @@
 0	0	0
-3
+23

That line is select count() from atf_p settings additional_table_filters = {'atf_p': 'x <= 2'} — the test sets parallel_replicas_local_plan=1, parallel_replicas_support_projection=1 and is being run here under the ParallelReplicas profile with randomized settings (use_hedged_requests, etc.). It's a projection + additional_table_filters + parallel-replicas query-correctness case with zero connection to part removal / zero-copy unlocking. Notably the GitHub Actions check-run for this same job concluded success (id 89449990776) — the harness treats this single miss as flaky/non-blocking; only the raw Altinity S3 status surfaces the Failed: 1. (Broken: 2 are expected broken_tests.yaml entries, not failures.)
→ Next step: re-run the job. If it recurs on retry it's a pre-existing parallel-replicas flake to track separately from this backport, not something this diff can influence.

3. PR — aggregate rollup

No independent failure; it's red only because it aggregates the two above. Clears once they re-run green.

---

Health check: The change is a clean, tightly-scoped backport of upstream ClickHouse#95597 touching only DataPartStorageOnDiskBase.cpp — it moves the can_remove_callback() (zero-copy reference check) evaluation to before disk->moveDirectory(from, to) so the check runs against the still-existing source path, and drops the now-redundant late evaluations in the FILE_DOESNT_EXIST branches. Everything in the PR's actual blast radius is green: Fast test, amd_binary/amd_debug builds, all Integration test shards (amd_binary 1–5/5), AST fuzzer (amd_debug), BuzzHouse, and all x86 Regression suites (iceberg, parquet, s3). I'd re-run the two red jobs and expect green; no code change is needed on my side.

_{— triaged by @blau-ai from CI logs (no local build/test in this environment)}