When inserting to Replicated table,
if the part was written to local filesystem but on commit to ZooKeeper, the connection to ZK is loss,
the client will get an error Unknown status, client must retry and the part will be scheduled for check.

The part will remain in filesystem and in the working set in memory. It's available for SELECT queries.

It's expected that the part will be checked and one of two possibilities will be found:

• the part was committed to ZooKeeper (along with replication log entry that's committed in the same transaction), we have to keep it;
• the part was not committed to ZooKeeper, we have to delete it from the filesystem and from the working set in memory.

But there is a case when the part was not committed to ZooKeeper but is not checked and remain in the filesystem and in the working set in memory forever (until clickhouse-server restart of until DETACH/ATTACH table).

It looks like diverged replicas (a replica has slightly more records than other replicas) and is fixed automatically by clickhouse-server restart.