We use Clickhouse version 22.3.3.44, and met with with some wrong behaviour - 
queries "ALTER TABLE ... MODIFY COMMENT ... " does not work on ReplicatedMergeTree engine.

Bug reproduce script:
```
CREATE TABLE sandbox.test__calendar
(
    `dttm` DateTime COMMENT 'date and time',
    `timestamp` Int64 COMMENT 'event timestamp',
    `year_num` Int32 COMMENT 'year number'
)
ENGINE = ReplicatedMergeTree() PARTITION BY year_num ORDER BY timestamp
COMMENT 'Comment text for test table';

SELECT comment FROM system.tables WHERE name like 'test__calendar'; -- 1 row selected with correct comment text

ALTER TABLE sandbox.test__calendar MODIFY COMMENT 'Some new more detailed text of comment';

SELECT comment FROM system.tables WHERE name like 'test__calendar'; -- 1 row selected, but with OLD(!) comment text
```

Maybe it will be helpfull, ALTER TABLE query returns such result:
```
host            |status|error|num_hosts_remaining|num_hosts_active|
----------------+------+----+-----------------------+------------------+
10.7.179.41     |     0|    |                      1|                 0|
ak1-st-data-01  |     0|    |                      0|                 0|
```
{
    auto zookeeper = getZooKeeper();
    Strings expected_parts_vec = zookeeper->getChildren(fs::path(replica_path) / "parts");
    
    NameSet expected_parts(expected_parts_vec.begin(), expected_parts_vec.end());
    
    auto parts = getDataParts({MergeTreeDataPartState::Active, MergeTreeDataPartState::Outdated});
    /** Local parts that are not in ZK.
      * In very rare cases they may cover missing parts
      * and someone may think that pushing them to zookeeper is good idea.
      * But actually we can't precisely determine that ALL missing parts
      * covered by this unexpected part. So missing parts will be downloaded.
      */
    DataParts unexpected_parts;
    
    for (const auto & part : parts)
        if (!expected_parts.contains(part->name))
            unexpected_parts.insert(part); 
    
    Strings parts_to_fetch;
    for (const String & missing_name : expected_parts)
        if (!getActiveContainingPart(missing_name))
            parts_to_fetch.push_back(missing_name);
    /** To check the adequacy, for the parts that are in the FS, but not in ZK, we will only consider not the most recent parts.
      * Because unexpected new parts usually arise only because they did not have time to enroll in ZK with a rough restart of the server.
      * It also occurs from deduplicated parts that did not have time to retire.
      */
    size_t unexpected_parts_nonnew = 0;