README: Datafuse -> Databend#1810
Merged
Merged
Conversation
Member
|
Thanks for the contribution! Please review the labels and make any necessary changes. |
Contributor
|
/LGTM |
databend-bot
approved these changes
Sep 13, 2021
Member
|
Approved! Thank you for the PR @bohutang |
|
Thank you very much for listening and committing to it! |
Member
Author
Thank you for your comprehension and arrow2. |
drmingdrmer
added a commit
to drmingdrmer/databend
that referenced
this pull request
Jun 30, 2026
# Summary Update the external meta service dependency to v260628.0.0 while keeping the direct meta client dependency pinned to the existing compatible version. # Details Refresh the databend-meta and databend-meta-test-harness pins together so the workspace uses the new external meta service release consistently. Update the compatibility docs through Databend 1.2.927, including the new external meta compatibility row and regenerated query/meta and raft peer compatibility tables. This upgrade including the OpenRaft bug fixes: # Bug Fixes: v0.10.0-alpha.20 → v0.10.0-alpha.27 Summary of every `fix:` commit in the range `v0.10.0-alpha.20..v0.10.0-alpha.27`. Ten fixes landed across seven releases (alpha.22 contained no bug fixes). ## At a glance | Release | Commit | Issue | Severity | One-line | |---------|--------|-------|----------|----------| | alpha.27 | `369e5d1c` | [databendlabs#1810](databendlabs/openraft#1810) | High (liveness) | A hung follower RPC could freeze the whole RaftCore loop | | alpha.26 | `01e813a5` | [databendlabs#1808](databendlabs/openraft#1808) | High (correctness) | Stale local membership survived a snapshot install | | alpha.25 | `d000ee20` | [databendlabs#1805](databendlabs/openraft#1805) | High (crash) | Premature transfer-leader election could panic on a vote outside the quorum | | alpha.25 | `f076cf6f` | [databendlabs#1802](databendlabs/openraft#1802) | **Critical (safety)** | Quorum scan could commit a value no real quorum reached | | alpha.24 | `d6a6d562` | [databendlabs#1796](databendlabs/openraft#1796) | High (liveness) | Rejected Pre-Vote dropped peer's higher term → election deadlock | | alpha.24 | `20c0b8ce` | — | Low (noise) | Completion-only writes logged spurious "dropped receiver" warnings | | alpha.24 | `19f2f037` | [databendlabs#1795](databendlabs/openraft#1795) | High (correctness) | Storage read error during replication retried a malformed AppendEntries | | alpha.23 | `d90df18f` | — | Medium (defensive) | `get_log_id_range` could return a reversed `(prev, last]` range | | alpha.21 | `13df5b32` | [databendlabs#1761](databendlabs/openraft#1761) | **Critical (crash)** | PurgeLog left stranded responders → panic permanently freezes the group | | alpha.21 | `bb142889` | — | Low (test infra) | Turmoil fuzzer falsely flagged a committed entry as lost after a voter crash | --- ## Critical fixes ### `13df5b32` — drain stranded client responders on PurgeLog (alpha.21, databendlabs#1761) - **Symptom:** A panic in the `RaftCore` task that *permanently freezes the entire Raft group*. - **Root cause:** When a follower lags past a snapshot's last index, `install_full_snapshot` skips the conflict-truncate step (the only path that drains client responders, because the local log never reaches that index) and instead removes superseded entries via `PurgeLog`. `PurgeLog` never touched `client_responders`, so a responder for a former leader's pending write stayed in the queue below the new purge boundary. The next apply then called `get_log_id(index).unwrap()` on a purged index and panicked. - **Fix:** `PurgeLog` now drains responders up to the purged index and completes each with `ForwardToLeader`, mirroring `TruncateLog`. In normal operation purge follows apply, so the drained range is empty and behavior is unchanged — it only fires on the snapshot-strand path. ### `f076cf6f` — keep VecProgress sorted above quorum (alpha.25, databendlabs#1802) - **Symptom:** A **safety violation** — the commit logic advances `quorum_accepted` to a value that no actual quorum of voters reached, i.e. it can report something as committed when it isn't. - **Root cause:** `VecProgress` keeps voters in a sorted prefix so the quorum scan can stop early. When a voter advanced *above* the existing `quorum_accepted` but didn't cross the previous quorum boundary, `move_up()` was skipped, breaking the sorted-prefix invariant the optimized scan relies on. The stale ordering then let the scan over-count. - **Fix:** `move_up()` now runs for every voter update whose new value is above `quorum_accepted`, while the (more expensive) quorum recalculation stays limited to values crossing the previous boundary. Regression test covers the five-voter sequence from databendlabs#1802 where `quorum_accepted` wrongly advanced to 6 with only two voters there. --- ## Liveness fixes ### `369e5d1c` — avoid blocking RaftCore on closed replication (alpha.27, databendlabs#1810) - **Symptom:** A hung follower RPC stalls `RaftCore`, so it can no longer process membership changes or new writes. - **Root cause:** Removed replication tasks were joined synchronously; a still-polling transport future on a dead/hung stream blocked the core loop. - **Fix:** Progress notifications now carry a stream id; `RaftCore` forwards it to the replication handler, which ignores stale progress from detached tasks after a stream is replaced. The response loop also watches the close signal while awaiting responses, enabling cooperative shutdown. Removed tasks are signaled and joined asynchronously. ### `d6a6d562` — adopt higher vote from rejected Pre-Vote (alpha.24, databendlabs#1796) - **Symptom:** Election deadlock — a lower-term cohort retries forever from stale terms and never converges. - **Root cause:** A rejected Pre-Vote response carries the responder's (higher) vote, but that term information was ignored, so stale nodes never learned a newer term existed. - **Fix:** A rejected Pre-Vote now advances the requester to the responder's strictly-higher vote in *non-committed* form — mirroring the rejected real-vote path while preserving Pre-Vote's side-effect-free request semantics (no real vote is granted). Adds engine-level coverage and a top-level integration reproduction. --- ## Correctness fixes ### `01e813a5` — reset purged membership on snapshot install (alpha.26, databendlabs#1808) - **Symptom:** A local effective membership survives even after its backing log entry is covered by an installed snapshot, leaving the membership cache out of sync with the snapshot. - **Root cause:** The snapshot membership install path didn't treat the snapshot's last index as a purge boundary, so a stale local effective membership whose log index was below the snapshot's last index was not reset. - **Fix:** The install path now receives the snapshot last log index and resets cached membership when the effective membership falls within the covered range, while keeping the existing log-id comparison for normal committed membership updates. Regression test covers a snapshot whose last membership has a lower index than the stale local one, yet whose last index still covers that local membership log. ### `19f2f037` — stop replication after storage read error (alpha.24, databendlabs#1795) - **Symptom:** A storage read error while generating `AppendEntries` looked like stream exhaustion (a "successful send"), so the leader retried a malformed payload — e.g. `prev_log_id=None` with a non-empty entries vector. - **Root cause:** The replication loop didn't distinguish a fatal read error from normal end-of-stream. - **Fix:** Records a fatal marker in the stream state after reporting the storage error to `RaftCore`; the owning loop checks it both after stream setup and after response consumption, so eager custom streaming transports and the default lazy path both stop immediately. Adds a debug assertion that a non-empty entries vector starts exactly after its `prev_log_id`, plus an integration regression test that injects a one-shot memstore read error. ### `d90df18f` — get_log_id_range never returns a reversed range (alpha.23) - **Symptom:** `get_log_id_range` could yield a reversed `(prev, last]` range (`prev > last`), producing an invalid `start >= end` for the log read. - **Root cause:** `prev` arrives via `ReplicationCore`'s command channel while `last` is observed through the `io_submitted` watch channel, which may lag behind; combining them directly could invert the range. - **Fix:** New `non_reversed_log_id_range()` helper clamps `last = max(last, prev)`; `read_log_entries` now treats `start >= end` as an empty (heartbeat) read, with a `debug_assert` guarding against a genuinely reversed range. Unit tests cover both the stale-`last` and normal cases. --- ## Crash fix ### `d000ee20` — reject stale transfer-leader target election (alpha.25, databendlabs#1805) - **Symptom:** A transfer target could panic in `Candidate::grant_by()` when it received a vote from a node outside its quorum progress — triggered during the promoted-learner window where the leader already treats a learner as a voter but the target hasn't yet replicated the promotion log. - **Root cause:** A transfer target started its leadership-transfer election before flushing the leader's expected log state, and `grant_by()` panicked on votes from nodes not in the quorum progress. - **Fix:** Transfer-leader requests now carry the leader's expected last log id; the target waits for matching flushed progress and returns a non-fatal `LogNotFlushed` or `VoteChanged` instead of blindly submitting an election. The transfer-leader network and public Raft APIs now return `TransferLeaderResponse` so callers can tell delivery failure from transfer rejection. `Candidate::grant_by()` now treats out-of-quorum votes as *ignored* rather than panicking. --- ## Low-impact / non-product fixes ### `20c0b8ce` — avoid commit channels for complete-only responders (alpha.24) - **Symptom:** Benign but misleading log noise — batch writes emitted a "dropped receiver" warning per entry. - **Root cause:** `ProgressResponder::new()` always creates both commit and completion channels, but completion-only callers (`client_write`, `client_write_many`) drop the commit receiver immediately. On commit, `on_commit()` tried to send through each abandoned channel and warned for every one. - **Fix:** Adds `ProgressResponder::complete_only()` for callers that only need the final result, used in completion-only write paths. ### `bb142889` — turmoil: count crashed voters in quorum check (alpha.21) - **Symptom:** A false positive in the turmoil fuzzer's safety checker — a committed entry was reported as "missing" merely because a voter crashed *after* persisting it. - **Root cause:** The committed-on-quorum invariant checked log presence only against *live* raft handles, ignoring durable state of crashed nodes. - **Fix:** The fuzzer now passes durable log-id snapshots into the invariant checker for the commit-quorum check, while leader/pairwise checks still use live snapshots (keeping stale crashed-node metrics out). Test-infrastructure only; no product code change.
5 tasks
drmingdrmer
added a commit
that referenced
this pull request
Jun 30, 2026
# Summary Update the external meta service dependency to v260628.0.0 while keeping the direct meta client dependency pinned to the existing compatible version. # Details Refresh the databend-meta and databend-meta-test-harness pins together so the workspace uses the new external meta service release consistently. Update the compatibility docs through Databend 1.2.927, including the new external meta compatibility row and regenerated query/meta and raft peer compatibility tables. This upgrade including the OpenRaft bug fixes: # Bug Fixes: v0.10.0-alpha.20 → v0.10.0-alpha.27 Summary of every `fix:` commit in the range `v0.10.0-alpha.20..v0.10.0-alpha.27`. Ten fixes landed across seven releases (alpha.22 contained no bug fixes). ## At a glance | Release | Commit | Issue | Severity | One-line | |---------|--------|-------|----------|----------| | alpha.27 | `369e5d1c` | [#1810](databendlabs/openraft#1810) | High (liveness) | A hung follower RPC could freeze the whole RaftCore loop | | alpha.26 | `01e813a5` | [#1808](databendlabs/openraft#1808) | High (correctness) | Stale local membership survived a snapshot install | | alpha.25 | `d000ee20` | [#1805](databendlabs/openraft#1805) | High (crash) | Premature transfer-leader election could panic on a vote outside the quorum | | alpha.25 | `f076cf6f` | [#1802](databendlabs/openraft#1802) | **Critical (safety)** | Quorum scan could commit a value no real quorum reached | | alpha.24 | `d6a6d562` | [#1796](databendlabs/openraft#1796) | High (liveness) | Rejected Pre-Vote dropped peer's higher term → election deadlock | | alpha.24 | `20c0b8ce` | — | Low (noise) | Completion-only writes logged spurious "dropped receiver" warnings | | alpha.24 | `19f2f037` | [#1795](databendlabs/openraft#1795) | High (correctness) | Storage read error during replication retried a malformed AppendEntries | | alpha.23 | `d90df18f` | — | Medium (defensive) | `get_log_id_range` could return a reversed `(prev, last]` range | | alpha.21 | `13df5b32` | [#1761](databendlabs/openraft#1761) | **Critical (crash)** | PurgeLog left stranded responders → panic permanently freezes the group | | alpha.21 | `bb142889` | — | Low (test infra) | Turmoil fuzzer falsely flagged a committed entry as lost after a voter crash | --- ## Critical fixes ### `13df5b32` — drain stranded client responders on PurgeLog (alpha.21, #1761) - **Symptom:** A panic in the `RaftCore` task that *permanently freezes the entire Raft group*. - **Root cause:** When a follower lags past a snapshot's last index, `install_full_snapshot` skips the conflict-truncate step (the only path that drains client responders, because the local log never reaches that index) and instead removes superseded entries via `PurgeLog`. `PurgeLog` never touched `client_responders`, so a responder for a former leader's pending write stayed in the queue below the new purge boundary. The next apply then called `get_log_id(index).unwrap()` on a purged index and panicked. - **Fix:** `PurgeLog` now drains responders up to the purged index and completes each with `ForwardToLeader`, mirroring `TruncateLog`. In normal operation purge follows apply, so the drained range is empty and behavior is unchanged — it only fires on the snapshot-strand path. ### `f076cf6f` — keep VecProgress sorted above quorum (alpha.25, #1802) - **Symptom:** A **safety violation** — the commit logic advances `quorum_accepted` to a value that no actual quorum of voters reached, i.e. it can report something as committed when it isn't. - **Root cause:** `VecProgress` keeps voters in a sorted prefix so the quorum scan can stop early. When a voter advanced *above* the existing `quorum_accepted` but didn't cross the previous quorum boundary, `move_up()` was skipped, breaking the sorted-prefix invariant the optimized scan relies on. The stale ordering then let the scan over-count. - **Fix:** `move_up()` now runs for every voter update whose new value is above `quorum_accepted`, while the (more expensive) quorum recalculation stays limited to values crossing the previous boundary. Regression test covers the five-voter sequence from #1802 where `quorum_accepted` wrongly advanced to 6 with only two voters there. --- ## Liveness fixes ### `369e5d1c` — avoid blocking RaftCore on closed replication (alpha.27, #1810) - **Symptom:** A hung follower RPC stalls `RaftCore`, so it can no longer process membership changes or new writes. - **Root cause:** Removed replication tasks were joined synchronously; a still-polling transport future on a dead/hung stream blocked the core loop. - **Fix:** Progress notifications now carry a stream id; `RaftCore` forwards it to the replication handler, which ignores stale progress from detached tasks after a stream is replaced. The response loop also watches the close signal while awaiting responses, enabling cooperative shutdown. Removed tasks are signaled and joined asynchronously. ### `d6a6d562` — adopt higher vote from rejected Pre-Vote (alpha.24, #1796) - **Symptom:** Election deadlock — a lower-term cohort retries forever from stale terms and never converges. - **Root cause:** A rejected Pre-Vote response carries the responder's (higher) vote, but that term information was ignored, so stale nodes never learned a newer term existed. - **Fix:** A rejected Pre-Vote now advances the requester to the responder's strictly-higher vote in *non-committed* form — mirroring the rejected real-vote path while preserving Pre-Vote's side-effect-free request semantics (no real vote is granted). Adds engine-level coverage and a top-level integration reproduction. --- ## Correctness fixes ### `01e813a5` — reset purged membership on snapshot install (alpha.26, #1808) - **Symptom:** A local effective membership survives even after its backing log entry is covered by an installed snapshot, leaving the membership cache out of sync with the snapshot. - **Root cause:** The snapshot membership install path didn't treat the snapshot's last index as a purge boundary, so a stale local effective membership whose log index was below the snapshot's last index was not reset. - **Fix:** The install path now receives the snapshot last log index and resets cached membership when the effective membership falls within the covered range, while keeping the existing log-id comparison for normal committed membership updates. Regression test covers a snapshot whose last membership has a lower index than the stale local one, yet whose last index still covers that local membership log. ### `19f2f037` — stop replication after storage read error (alpha.24, #1795) - **Symptom:** A storage read error while generating `AppendEntries` looked like stream exhaustion (a "successful send"), so the leader retried a malformed payload — e.g. `prev_log_id=None` with a non-empty entries vector. - **Root cause:** The replication loop didn't distinguish a fatal read error from normal end-of-stream. - **Fix:** Records a fatal marker in the stream state after reporting the storage error to `RaftCore`; the owning loop checks it both after stream setup and after response consumption, so eager custom streaming transports and the default lazy path both stop immediately. Adds a debug assertion that a non-empty entries vector starts exactly after its `prev_log_id`, plus an integration regression test that injects a one-shot memstore read error. ### `d90df18f` — get_log_id_range never returns a reversed range (alpha.23) - **Symptom:** `get_log_id_range` could yield a reversed `(prev, last]` range (`prev > last`), producing an invalid `start >= end` for the log read. - **Root cause:** `prev` arrives via `ReplicationCore`'s command channel while `last` is observed through the `io_submitted` watch channel, which may lag behind; combining them directly could invert the range. - **Fix:** New `non_reversed_log_id_range()` helper clamps `last = max(last, prev)`; `read_log_entries` now treats `start >= end` as an empty (heartbeat) read, with a `debug_assert` guarding against a genuinely reversed range. Unit tests cover both the stale-`last` and normal cases. --- ## Crash fix ### `d000ee20` — reject stale transfer-leader target election (alpha.25, #1805) - **Symptom:** A transfer target could panic in `Candidate::grant_by()` when it received a vote from a node outside its quorum progress — triggered during the promoted-learner window where the leader already treats a learner as a voter but the target hasn't yet replicated the promotion log. - **Root cause:** A transfer target started its leadership-transfer election before flushing the leader's expected log state, and `grant_by()` panicked on votes from nodes not in the quorum progress. - **Fix:** Transfer-leader requests now carry the leader's expected last log id; the target waits for matching flushed progress and returns a non-fatal `LogNotFlushed` or `VoteChanged` instead of blindly submitting an election. The transfer-leader network and public Raft APIs now return `TransferLeaderResponse` so callers can tell delivery failure from transfer rejection. `Candidate::grant_by()` now treats out-of-quorum votes as *ignored* rather than panicking. --- ## Low-impact / non-product fixes ### `20c0b8ce` — avoid commit channels for complete-only responders (alpha.24) - **Symptom:** Benign but misleading log noise — batch writes emitted a "dropped receiver" warning per entry. - **Root cause:** `ProgressResponder::new()` always creates both commit and completion channels, but completion-only callers (`client_write`, `client_write_many`) drop the commit receiver immediately. On commit, `on_commit()` tried to send through each abandoned channel and warned for every one. - **Fix:** Adds `ProgressResponder::complete_only()` for callers that only need the final result, used in completion-only write paths. ### `bb142889` — turmoil: count crashed voters in quorum check (alpha.21) - **Symptom:** A false positive in the turmoil fuzzer's safety checker — a committed entry was reported as "missing" merely because a voter crashed *after* persisting it. - **Root cause:** The committed-on-quorum invariant checked log presence only against *live* raft handles, ignoring durable state of crashed nodes. - **Fix:** The fuzzer now passes durable log-id snapshots into the invariant checker for the commit-quorum check, while leader/pairwise checks still use live snapshots (keeping stale crashed-node metrics out). Test-infrastructure only; no product code change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I hereby agree to the terms of the CLA available at: https://datafuse.rs/policies/cla/
Summary
README.md Datafuse -> Databend
Changelog
Related Issues
Fixes N/A
Test Plan
Unit Tests
Stateless Tests