No rows are written, though. Still, this may be problematic when this insert fails due to the `too many parts` error, which leads to the parent insert also failing. I haven't reproduced this failure exactly (complicated to do on localhost), but seen it happen for a ClickHouse user in Yandex.

Apparently this only happens with `insert_distributed_sync = 1`.

Cluster config:
```
        <weighted>
            <shard>
                <weight>100</weight>
                <replica>
                    <host>127.0.0.2</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <weight>0</weight>
                <replica>
                    <host>127.0.0.3</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <weight>100</weight>
                <replica>
                    <host>127.0.0.4</host>
                    <port>9000</port>
                </replica>
            </shard>
        </weighted>
```

Queries:

```
create table t_local (a int) engine MergeTree order by (a);

create table t_dist (a int) engine Distributed(weighted, 'default', 't_local', cityHash64(a));

set insert_distributed_sync = 1;

select written_rows, query_id from system.query_log where initial_query_id = '4c93852e-bdcb-436a-9ad3-4953ccedfcdc' and type != 1;
```

In the query log we see that the query is sent to all three shards, including the one with zero weight, but no rows are sent there.
```
SELECT 
    written_rows,
    query_id
FROM system.query_log
WHERE (initial_query_id = '4c93852e-bdcb-436a-9ad3-4953ccedfcdc') AND (type != 1)

┌─written_rows─┬─query_id─────────────────────────────┐
│            0 │ 177294a7-5612-45ef-bb57-2b36b73d709f │
│       499720 │ 02d724ae-5840-4805-9e5f-747a85332545 │
│       500280 │ a4692444-5409-4aec-a821-d9095e912ca1 │
│      1000000 │ 4c93852e-bdcb-436a-9ad3-4953ccedfcdc │
└──────────────┴──────────────────────────────────────┘
```

For more fun, try the `Log` engine for `t_local` -- the insert deadlocks: https://github.com/ClickHouse/ClickHouse/issues/14570
if (num_shard_rows)
                    dst_column = src_column->permute(shard_permutation, num_shard_rows);
                else
                    dst_column = src_column->cloneEmpty();
            }
        }
        const Block & shard_block = (num_shards > 1) ? job.current_shard_block : current_block;
        const Settings & settings = context.getSettingsRef();
        if (!job.is_local_job || !settings.prefer_localhost_replica)
        {
            if (!job.stream)
            {
                auto timeouts = ConnectionTimeouts::getTCPTimeoutsWithFailover(settings);
                if (shard_info.hasInternalReplication())
                {
                    
                    if (shard_job.replicas_jobs.size() != 1)
                        throw Exception("There are several writing job for an automatically replicated shard", ErrorCodes::LOGICAL_ERROR);
                    
                    auto connections = shard_info.pool->getMany(timeouts, &settings, PoolMode::GET_ONE);
                    if (connections.empty() || connections.front().isNull())
                        throw Exception("Expected exactly one connection for shard " + toString(job.shard_index), ErrorCodes::LOGICAL_ERROR);
                    job.connection_entry = std::move(connections.front());
                }
                else
                {
                    const auto & replica = addresses.at(job.shard_index).at(job.replica_index);
                    const ConnectionPoolPtr & connection_pool = shard_info.per_replica_pools.at(job.replica_index);
                    if (!connection_pool)
                        throw Exception("Connection pool for replica " + replica.readableString() + " does not exist", ErrorCodes::LOGICAL_ERROR);