Ping Yu

Still get & pass `revision` to update GC safe point interface. _p.s. In this scenario, `revision` will be `-1._

> @pingyu What `revision` is returned from `GetGCMinServiceSafePointByServiceGroup` interface in this scenario? `-1`. See [here](https://github.com/AmoebaProtozoa/pd/blob/2965b74dfbd1fd7a8ac9ddef94acb4c5040d5832/server/storage/kv/kv.go#L17). > Could gc-worker pass the returned `revision` to `UpdateGCSafePointByServiceGroup` or need hard code to `-1`?...

@tisonkun I want to write this chapter. Please assign to me, thanks~

References: [TiKV IO rate limiter - Spec](https://docs.google.com/document/d/1Jdsi7Ah1YtlZ3trCenqOL3BQ0FyeeubPJwyGwPeUdXM/edit?usp=sharing) [TiKV IO rate limiter - phase 1](https://github.com/tikv/tikv/issues/9156)

Hi @dongb0 , thanks for your attention. It is expected to serve as a guide for TiKV development. But it is far from finished now, and there is a lack...

When `REPLICAS` is `0/1`, the PD & TiKV was not started normally. The docs of v3.0 would be out-of-date. Please try to start a TiKV cluster by TiUP. See https://github.com/tikv/client-rust?tab=readme-ov-file#building-and-testing.

Currently integration tests are hard coded to `v2`. Set clients to use API `v1` by `TransactionClient::new()` or `RawClient::new()`. To address the error, you may also need to use a `v1`...

I meant the error was raised from [`clear_tikv()`](https://github.com/tikv/client-rust/blob/c6110dd8087a4d9e7bf48da77bbbfafa79614b10/tests/common/mod.rs#L29). Change the `Config::default().with_default_keyspace()` in the following two lines to `Config::default()`. ```rust let raw_client = RawClient::new_with_config(pd_addrs(), Config::default().with_default_keyspace()) ... ... let txn_client = TransactionClient::new_with_config(pd_addrs(),...

Emmm... `txn_client.unsafe_destroy_range(..)` is not allowed in API v1. Just comment out the the two lines. It's not necessary in API v1. ``` let txn_client = TransactionClient::new_with_config(pd_addrs(), Config::default().with_default_keyspace()) .await .unwrap(); txn_client.unsafe_destroy_range(..).await.unwrap();...

> is this expected? No. There seems to be bugs.