Fixed linter errors

Author: anton-bobkov

ydb/docs/en/core/concepts/topic.md

@@ -129,7 +129,7 @@ A source ID is an arbitrary string up to 2048 characters long. This is usually t
 #### Sample source IDs {#source-id-examples}
 
 | Type | ID | Description |
---- | --- | ---
+| --- | --- | --- |
 | File | Server ID | Files are used to store application logs. In this case, it's convenient to use the server ID as a source ID. |
 | User actions | ID of the class of user actions, such as "viewing a page", "making a purchase", and so on. | It's important to handle user actions in the order they were performed by the user. At the same time, there is no need to handle every single user action in one application. In this case, it's convenient to group user actions by class. |
 
@@ -140,7 +140,7 @@ A message group ID is an arbitrary string up to 2048 characters long. This is us
 #### Sample message group IDs {#group-id-examples}
 
 | Type | ID | Description |
---- | --- | ---
+| --- | --- | --- |
 | File | Full file path | All data from the server and the file it hosts will be sent to the same partition. |
 | User actions | User ID | It's important to handle user actions in the order they were performed. In this case, it's convenient to use the user ID as a source ID. |
 
@@ -153,9 +153,9 @@ Sequence numbers are not used if [no-deduplication mode](#no-dedup) is enabled.
 ### Sample message sequence numbers {#seqno-examples}
 
 | Type | Example | Description |
---- | --- | ---
+| --- | --- | --- |
 | File | Offset of transferred data from the beginning of a file | You can't delete lines from the beginning of a file, since this will lead to skipping some data as duplicates or losing some data. |
-| DB table | Auto-increment record ID |
+| DB table | Auto-increment record ID | |
 
 ## Message retention period {#retention-time}
 
@@ -168,13 +168,13 @@ When transferring data, the producer app indicates that a message can be compres
 Supported codecs are explicitly listed in each topic. When making an attempt to write data to a topic with a codec that is not supported, a write error occurs.
 
 | Codec | Description |
---- | ---
+| --- | --- |
 | `raw` | No compression. |
 | `gzip` | [Gzip](https://en.wikipedia.org/wiki/Gzip) compression. |
 {% if audience != "external" %}
-`lzop` | [lzop](https://en.wikipedia.org/wiki/Lzop) compression.
+| `lzop` | [lzop](https://en.wikipedia.org/wiki/Lzop) compression. |
 {% endif %}
-`zstd` | [zstd](https://en.wikipedia.org/wiki/Zstd) compression.
+| `zstd` | [zstd](https://en.wikipedia.org/wiki/Zstd) compression. |
 
 ## Consumer {#consumer}
 

ydb/docs/en/core/contributor/load-actors-kqp.md

@@ -14,7 +14,7 @@ Before this test, the necessary tables are created. After it's completed, they a
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `DurationSeconds` | Load duration in seconds. |
 | `WindowDuration` | Statistics aggregation window duration. |
 | `WorkingDir` | Path to the directory to create test tables in. |

ydb/docs/en/core/contributor/load-actors-memory.md

@@ -11,7 +11,7 @@ This ad-hoc actor is used for testing specific functionality. This is not a load
 ## Actor parameters {#options}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `DurationSeconds` | Load duration in seconds. |
 | `BlockSize` | Allocated block size in bytes. |
 | `IntervalUs` | Interval between block allocations in microseconds. |

ydb/docs/en/core/contributor/load-actors-pdisk-log.md

@@ -15,7 +15,7 @@ This ad-hoc actor is used for testing specific functionality. This is not a load
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `PDiskId` | ID of the Pdisk being loaded on the node. |
 | `PDiskGuid` | Globally unique ID of the PDisk being loaded. |
 | `VDiskId` | Parameters of the VDisk used to generate load.<ul><li>`GroupID`: Group ID.</li><li>`GroupGeneration`: Group generation.</li><li>`Ring`: Group ring ID.</li><li>`Domain`: Ring fail domain ID.</li><li>`VDisk`: Index of the VDisk in the fail domain.</li></ul> |

ydb/docs/en/core/contributor/load-actors-pdisk-read.md

@@ -12,7 +12,7 @@ You can generate two types of load:
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `PDiskId` | ID of the Pdisk being loaded on the node. |
 | `PDiskGuid` | Globally unique ID of the PDisk being loaded. |
 | `VDiskId` | The load is generated on behalf of a VDisk with the following parameters:<ul><li>`GroupID`: Group ID.</li><li>`GroupGeneration`: Group generation.</li><li>`Ring`: Group ring ID.</li><li>`Domain`: Ring fail domain ID.</li><li>`VDisk`: Index of the VDisk in the fail domain.</li></ul> |

ydb/docs/en/core/contributor/load-actors-pdisk-write.md

@@ -12,7 +12,7 @@ You can generate two types of load:
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `PDiskId` | ID of the Pdisk being loaded on the node. |
 | `PDiskGuid` | Globally unique ID of the PDisk being loaded. |
 | `VDiskId` | The load is generated on behalf of a VDisk with the following parameters:<ul><li>`GroupID`: Group ID.</li><li>`GroupGeneration`: Group generation.</li><li>`Ring`: Group ring ID.</li><li>`Domain`: Ring fail domain ID.</li><li>`VDisk`: Index of the VDisk in the fail domain.</li></ul> |

ydb/docs/en/core/contributor/load-actors-stop.md

@@ -5,7 +5,7 @@ Using this command, you can stop either entire load or only the specified part o
 ## Actor parameters {#options}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `Tag` | Tag of the load actor to stop. You can view the tag in the cluster Embedded UI. |
 | `RemoveAllTags` | If this parameter value is set to `True`, all the load actors are stopped. |
 

ydb/docs/en/core/contributor/load-actors-storage.md

@@ -13,7 +13,7 @@ You can generate three types of load:
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `DurationSeconds` | Load duration. The timer starts upon completion of the initial data allocation. |
 | `Tablets` | The load is generated on behalf of a tablet with the following parameters:<ul><li>`TabletId`: Tablet ID. It must be unique for each load actor across all the cluster nodes. This parameter and `TabletName` are mutually exclusive.</li><li>`TabletName`: Tablet name. If the parameter is set, tablets' IDs will be assigned automatically, tablets launched on the same node with the same name will be given the same ID, tablets launched on different nodes will be given different IDs.</li><li>`Channel`: Tablet channel.</li><li>`GroupId`: ID of the storage group to get loaded.</li><li>`Generation`: Tablet generation.</li></ul> |
 | `WriteSizes` | Size of the data to write. It is selected randomly for each request from the `Min`-`Max` range. You can set multiple `WriteSizes` ranges, in which case a value from a specific range will be selected based on its `Weight`. |
@@ -32,15 +32,15 @@ You can generate three types of load:
 ### Write requests class {#write-class}
 
 | Class | Description |
---- | ---
+| --- | --- |
 | `TabletLog` | The highest priority of write operation. |
 | `AsyncBlob` | Used for writing SSTables and their parts. |
 | `UserData` | Used for writing user data as separate blobs. |
 
 ### Read requests class {#read-class}
 
 | Class | Description |
---- | ---
+| --- | --- |
 | `AsyncRead` | Used for reading compacted tablets' data. |
 | `FastRead` | Used for fast reads initiated by user. |
 | `Discover` | Reads from Discover query. |
@@ -53,14 +53,14 @@ You can generate three types of load:
 ### Parameters of load with hard rate {#hard-rate-dispatcher}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `RequestRateAtStart` | Requests per second at the moment of load start. If load duration limit is not set then the request rate will remain the same and equal to the value of this parameter. |
 | `RequestRateOnFinish` | Requests per second at the moment of load finish. |
 
 ### Parameters of initial data allocation {#initial-allocation}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `TotalSize` | Total size of allocated data. This parameter and `BlobsNumber` are mutually exclusive. |
 | `BlobsNumber` | Total number of allocated blobs. |
 | `BlobSizes` | Size of the blobs to write. It is selected randomly for each request from the `Min`-`Max` range. You can set multiple `WriteSizes` ranges, in which case a value from a specific range will be selected based on its `Weight`. |

ydb/docs/en/core/contributor/load-actors-vdisk.md

@@ -7,7 +7,7 @@ Generates a write-only load on the VDisk. Simulates a Distributed Storage Proxy.
 {% include [load-actors-params](../_includes/load-actors-params.md) %}
 
 | Parameter | Description |
---- | ---
+| --- | --- |
 | `VDiskId` | Parameters of the VDisk used to generate load.<ul><li>`GroupID`: Group ID.</li><li>`GroupGeneration`: Group generation.</li><li>`Ring`: Group ring ID.</li><li>`Domain`: Ring fail domain ID.</li><li>`VDisk`: Index of the VDisk in the fail domain.</li></ul> |
 | `GroupInfo` | Description of the group hosting the loaded VDisk (of the appropriate generation). |
 | `TabletId` | ID of the tablet that generates the load. It must be unique for each load actor. |

ydb/docs/en/core/contributor/localdb-uncommitted-txs.md

@@ -29,38 +29,38 @@ Redo log (see [flat_redo_writer.h](https://github.com/ydb-platform/ydb/blob/main
 [MemTable](../concepts/glossary.md#memtable) in LocalDB is a relatively small in-memory sorted tree that maps table keys to values. MemTable value is a chain of MVCC (partial) rows, each tagged with a row version (a pair of Step and TxId which is a global timestamp). Rows are normally pre-merged across the given MemTable. For example, let's suppose there have been the following operations for some key K:
 
 | Version | Operation |
---- | ---
+| --- | --- |
 | `v1000/10` | `UPDATE ... SET A = 1` |
 | `v2000/11` | `UPDATE ... SET B = 2` |
 | `v3000/12` | `UPDATE ... SET C = 3` |
 
 Then the chain of rows for key K in a single MemTable will look like this:
 
 | Version | Row |
---- | ---
+| --- | --- |
 | `v3000/12` | `SET A = 1, B = 2, C = 3` |
 | `v2000/11` | `SET A = 1, B = 2` |
 | `v1000/10` | `SET A = 1` |
 
 However, if the MemTable was split between updates, it may look like this:
 
 | MemTable | Version | Row |
---- | --- | ---
+| --- | --- | --- |
 | Epoch 2 | `v3000/12` | `SET B = 2, C = 3` |
 | Epoch 2 | `v2000/11` | `SET B = 2` |
 | Epoch 1 | `v1000/10` | `SET A = 1` |
 
 Changes are applied to the current MemTable, and uncommitted changes are no exception. However, they are tagged with a special version (where Step is the maximum possible number, as if they are in some "distant" future, and TxId is their uncommitted TxId), without any pre-merging. For example, let's suppose we additionally performed the following operations:
 
 | TxId | Operation |
---- | ---
+| --- | --- |
 | 15 | `UPDATE ... SET C = 10` |
 | 13 | `UPDATE ... SET B = 20` |
 
 The update chain for our key K will look like this:
 
 | Version | Row |
---- | ---
+| --- | --- |
 | `v{max}/13` | `SET B = 20` |
 | `v{max}/15` | `SET C = 10` |
 | `v3000/12` | `SET A = 1, B = 2, C = 3` |
@@ -74,7 +74,7 @@ Let's suppose we commit tx 13 at `v4000/20`. At that point transaction map is up
 Let's suppose we now perform an `UPDATE ... SET A = 30` at version `v5000/21`, the resulting chain will look as follows:
 
 | Version | Row |
---- | ---
+| --- | --- |
 | `v5000/21` | `SET A = 30, B = 20, C = 3` |
 | `v{max}/13` | `SET B = 20` |
 | `v{max}/15` | `SET C = 10` |
@@ -93,7 +93,7 @@ Data pages (see [flat_page_data.h](https://github.com/ydb-platform/ydb/blob/main
 One key may have several uncommitted delta records, as well as (optionally) the latest committed record data. Historically, data pages could only have one record (and one record pointer) per key, so the record pointer leads to the top of the delta chain, and other records are available via additional per-record offset table for other records:
 
 | Offset | Description |
---- | ---
+| --- | --- |
 | -X*8 | offset of Main |
 | ... | ... |
 | -16 | offset of Delta 2 |
@@ -109,7 +109,7 @@ Having a pointer to Delta 0, other records for the same key are available with t
 Let's suppose that after writing tx 13 above the MemTable was compacted. Entry for the 32-bit key K may look like this (offsets are relative to the record pointer on the table):
 
 | Offset | Value | Description |
---- | --- | ---
+| --- | --- | --- |
 | -16 | 58 | offset of Main |
 | -8 | 29 | offset of Delta 1 |
 | 0 | 0x21 | Delta 0: IsDelta + ERowOp::Upsert |