CAS: `ATTACH PARTITION FROM` local disk to CAS disk fails with `ref 'tmp_replace_from_1_1_1_0' already names a different committed manifest`

[alsugiliazova]

Describe the issue

ALTER TABLE <dst> ATTACH PARTITION <id> FROM <src>, where the source is a plain
local-disk MergeTree and the destination is a MergeTree on a
CAS disk (metadata_type = content_addressed), fails on the very first ATTACH
with a CAS unique-ref collision:

Code: 210. DB::Exception: CAS write could not be committed
(promote: ref 'tmp_replace_from_1_1_1_0' already names a different committed manifest
 — refusing to overwrite (unique-ref invariant; use republishRef for an intended repoint));
retrying later. (NETWORK_ERROR)

---

How to reproduce the behavior

Environment

• Version: 26.6.2.20000.altinityantalya (arm64)
• Build type: release from commit 9b5cbc3

Storage configuration

<cas_disk>
    <type>object_storage</type>
    <object_storage_type>s3</object_storage_type>
    <metadata_type>cas</metadata_type>
    <server_root_id>cas-{replica}</server_root_id>
    <endpoint>http://minio:9000/warehouse/data/cas/</endpoint>
</cas_disk>
<policies>
    <cas_policy>
        <volumes><main><disk>cas_disk</disk></main></volumes>
    </cas_policy>
</policies>

Steps

1. Create a local-disk MergeTree source with a few partitions of data.

CREATE TABLE src
(
    a UInt16, b UInt16, c UInt16, extra UInt64,
    Path String, Time DateTime, Value Float64, Timestamp Int64, sign Int8
)
ENGINE = MergeTree PARTITION BY a ORDER BY a
SETTINGS disk = 'default';

INSERT INTO src (a, b, c, extra, sign) SELECT 1, 5, 9, number + 1000, 1 FROM numbers(4);

2. Create a MergeTree destination on the CAS disk.

CREATE TABLE dst
(
    a UInt16, b UInt16, c UInt16, extra UInt64,
    Path String, Time DateTime, Value Float64, Timestamp Int64, sign Int8
)
ENGINE = MergeTree PARTITION BY a ORDER BY a
SETTINGS storage_policy = 'cas_policy';

3. Attach a partition across disks (local → CAS).

ALTER TABLE dst ATTACH PARTITION 1 FROM src;

---

Expected behavior

In perfect world, the cross-disk ATTACH PARTITION 1 FROM src should succeed, byte-copy the part into
CAS, and make the rows of partition 1 visible in dst.

If the attach genuinely cannot be completed across the two disks, it should fail with
the established cross-disk-attach error contract, not with NETWORK_ERROR. The alter
suite's baseline for an incompatible cross-disk ATTACH PARTITION FROM is
Code: 36 (BAD_ARGUMENTS) "Could not clone and load part".

---

[filimonov]

Confirmed. Issue is real and fix is simple, will do tomorrow.

[filimonov]

Fixed in c5467b8 cfe9a6a 6b4ae80 98faaed f26f322

[filimonov]

Fixed in antalya-26.6 by 84b30f6 (merged via #2300; the five commit hashes above were squashed into it). Covered by 05025_cas_attach_partition_cross_disk, which runs the local → CAS ATTACH PARTITION FROM from this report. First release with the fix: 26.6.4.20001.altinityantalya.