From cac577a073f86251dad17759329e11819080e6a5 Mon Sep 17 00:00:00 2001 From: "min.tian" Date: Mon, 6 Dec 2021 18:00:07 +0800 Subject: [PATCH] [skip ci] Check the grammar of root_coord_recovery docs (#12746) Signed-off-by: min.tian --- docs/design_docs/root_coordinator_recovery_on_power_failure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design_docs/root_coordinator_recovery_on_power_failure.md b/docs/design_docs/root_coordinator_recovery_on_power_failure.md index e7ed27ace7..a96947f84c 100644 --- a/docs/design_docs/root_coordinator_recovery_on_power_failure.md +++ b/docs/design_docs/root_coordinator_recovery_on_power_failure.md @@ -33,7 +33,7 @@ ### 2.3 `create index` requests from grpc 1. In the processing of `create index`, `RC` calls `metaTable`'s `GetNotIndexedSegments` to get all segment ids that are not indexed -2. After getting the segment ids, `RC` call `IC` to create index on these segment ids. +2. After getting the segment ids, `RC` calls `IC` to create index on these segment ids. 3. In the current implementation, the `create index` requests will return after the segment ids are put into a go channel. 4. The `RC` starts a background task that keeps reading the segment ids from the go channel, and then calls the `IC` to create the index. 5. There is a fault here, the segment ids have been put into the go channel in the processing function of the grpc request, and then the grpc returns, but the `RC`'s background task has not yet read them from the go channel, then `RC` crashes. At this time, the client thinks that the index is created, but the `RC` does not call `IC` to create the index.