From 37d1da381db7682ea2335e704b31929f911c7492 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=BC=A0=E7=82=8E=E6=B3=BC?= <drdr.xp@gmail.com>
Date: Thu, 16 May 2024 15:04:27 +0800
Subject: [PATCH] Doc: add change-log 0.9.11

---
 change-log.md         | 50 +++++++++++++++++++++++++++++++++++++++++++
 change-log/v0.9.11.md | 47 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)
 create mode 100644 change-log/v0.9.11.md

diff --git a/change-log.md b/change-log.md
index 7bd23ace8..5d63c09d0 100644
--- a/change-log.md
+++ b/change-log.md
@@ -1,3 +1,53 @@
+## v0.9.11
+
+Summary:
+
+- Fixed:
+    -   [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log.
+
+Detail:
+
+### Fixed:
+
+-   Fixed: [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log; by 张炎泼; 2024-05-14
+
+    This commit addresses a critical issue where if a new leader does not
+    flush the blank log to disk upon becoming established and then restarts
+    immediately, there is a possibility that previously committed data
+    becomes invisible to readers.
+
+    Before the blank log is flushed, the leader (identified by vote `v3`)
+    assumes it will be flushed and commits this log once (|quorum|-1)
+    replication responses are received. If the blank log is lost and the
+    server is restarted, data committed by a new leader (vote `v2`) may
+    not be visible.
+
+    This issue is addressed by utilizing `LeaderHandler::leader_append_entries()`
+    instead of `ReplicationHandler::append_blank_log()`, where the former
+    does not wait for the blank log to flush.
+
+    Changes:
+
+    - When assigning log IDs to log entries, the `Leading.last_log_id`,
+      which represents the state of the log proposer (equivalent term in
+      Paxos is Proposer), should be used instead of `RaftState.last_log_id`,
+      which represents the state of the log receiver (equivalent term in
+      Paxos is Acceptor).
+
+    - Consequently, the method `assign_log_ids()` has been moved from
+      `RaftState` to `Leading`.
+
+    - Avoid manual implementation of duplicated logic:
+
+      - During `initialize()`, reuse `FollowingHandler::do_append_entries()`
+        to submit the very first log to storage.
+
+      - In `establish_leader()`, reuse
+        `LeaderHandler::leader_append_entries()` to submit log to storage
+        and remove `ReplicationHandler::append_blank_log()`.
+
+      - Remove `Command::AppendEntry`.
+
 ## v0.9.10
 
 Summary:
diff --git a/change-log/v0.9.11.md b/change-log/v0.9.11.md
new file mode 100644
index 000000000..bce17fd34
--- /dev/null
+++ b/change-log/v0.9.11.md
@@ -0,0 +1,47 @@
+Summary:
+
+- Fixed:
+    -   [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log.
+
+Detail:
+
+### Fixed:
+
+-   Fixed: [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log; by 张炎泼; 2024-05-14
+
+    This commit addresses a critical issue where if a new leader does not
+    flush the blank log to disk upon becoming established and then restarts
+    immediately, there is a possibility that previously committed data
+    becomes invisible to readers.
+
+    Before the blank log is flushed, the leader (identified by vote `v3`)
+    assumes it will be flushed and commits this log once (|quorum|-1)
+    replication responses are received. If the blank log is lost and the
+    server is restarted, data committed by a new leader (vote `v2`) may
+    not be visible.
+
+    This issue is addressed by utilizing `LeaderHandler::leader_append_entries()`
+    instead of `ReplicationHandler::append_blank_log()`, where the former
+    does not wait for the blank log to flush.
+
+    Changes:
+
+    - When assigning log IDs to log entries, the `Leading.last_log_id`,
+      which represents the state of the log proposer (equivalent term in
+      Paxos is Proposer), should be used instead of `RaftState.last_log_id`,
+      which represents the state of the log receiver (equivalent term in
+      Paxos is Acceptor).
+
+    - Consequently, the method `assign_log_ids()` has been moved from
+      `RaftState` to `Leading`.
+
+    - Avoid manual implementation of duplicated logic:
+
+      - During `initialize()`, reuse `FollowingHandler::do_append_entries()`
+        to submit the very first log to storage.
+
+      - In `establish_leader()`, reuse
+        `LeaderHandler::leader_append_entries()` to submit log to storage
+        and remove `ReplicationHandler::append_blank_log()`.
+
+      - Remove `Command::AppendEntry`.