• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

databendlabs / openraft / 16498629934
88%
main: 88%

Build:
Build:
LAST BUILD BRANCH: release-0.10
DEFAULT BRANCH: main
Ran 24 Jul 2025 01:51PM UTC
Jobs 1
Files 193
Run time 3min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

24 Jul 2025 06:44AM UTC coverage: 90.979% (+0.02%) from 90.963%
16498629934

push

github

drmingdrmer
Improve: Ensure uniform membership config during config changes

This commit improves the handling of membership configuration changes to
ensure that the system reliably transitions to a uniform configuration
in the second step of a joint membership change.

### Problem:

During a membership config change, there are two steps:

1. Transition to a joint configuration containing both `Cold` (current
   config) and `Cnew` (new config).
2. Transition to a uniform configuration containing only `Cnew`.

Previously, the second step attempted to apply the same change on the
current membership state. If multiple membership change requests were
processed in parallel, this approach could result in the system being
left in a joint configuration. For example:

- Initial config: `{a, b, c}`.
- Task 1: `AddVoterIds(x)`. After the first step:
  `[{a, b, c}, {a, b, c, x}]`.

- Task 2: `RemoveVoters(x)`. After the first step:
  `[{a, b, c, x}, {a, b, c}]` (applied on the last config `{a, b, c, x}`).

- Task 1 proceeds to the second step, re-applies `AddVoterIds(x)`, and
  the result is `[{a, b, c}, {a, b, c, x}]`.

- The system remains in a joint configuration, which is unintuitive and
  contradicts standard Raft expectations.

### Solution:

The second step now applies an **empty change request**
(`AddVoterIds({})`) to the last configuration in the current joint
config. This ensures that the system always transitions to a uniform
configuration in the second step.

### Impact:

- No behavior changes occur if only one membership change request is in
  progress.

- If multiple requests are processed concurrently, the application must
  still verify the result, and the new behavior ensures the system
  transitions to a uniform state.

This fix prevents the system from being left in an unintended joint
configuration, improving consistency and adherence to Raft principles.

Thanks to @tvsfx for providing feedback on this issue and offering a
detailed explanation of the solution.

11195 of 12305 relevant lines covered (90.98%)

89273.88 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
1
82.09
0.0% openraft/src/metrics/serde_instant.rs
Jobs
ID Job ID Ran Files Coverage
1 16498629934.1 24 Jul 2025 01:51PM UTC 193
90.98
GitHub Action Run
Source Files on build 16498629934
  • Tree
  • List 193
  • Changed 5
  • Source Changed 2
  • Coverage Changed 5
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #16498629934
  • 37d69439 on github
  • Prev Build on release-0.10 (#16488668865)
  • Next Build on release-0.10 (#16666545163)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc