[Qian-Cheng-nju]

When a newly elected leader inherits an uncommitted membership change, become_leader() copies the latest configuration into a new log entry but does not update uncommitted_config_. A priority change before that entry commits can therefore copy the older committed configuration and undo the inherited membership change.

Set uncommitted_config_ to last_config_cloned in become_leader() so subsequent priority changes build on the latest configuration. Priority changes remain allowed while the election configuration is pending.

Extend the existing failure and leader-election tests to cover:

• An inherited, uncommitted removal followed by a priority change, checking both the appended configuration and the committed configurations on the remaining nodes.
• A priority change immediately after an ordinary election, checking that it is accepted and committed without changing membership.

Validation:

• On upstream d046042b, the membership regression fails because the priority configuration reintroduces the removed server; the ordinary-election variants pass.
• With the fix, all 10 CTest suites pass with DISABLE_ASIO=ON.
• The complete runtests.sh script passes with Asio, AddressSanitizer, and Raft statistics enabled.

[greensky00]

Hi @Qian-Cheng-nju , thanks for the PR, and sorry for the slow review.

First, changing the priority before the config created at leader election is committed is not a problem. That config is a copy of the latest config with only the log index changed and no membership change. Building a priority change on top of it is therefore safe.

There is one real issue, though. When a member becomes the new leader, it checks for uncommitted config entries in its log. If it finds one, any later priority change should be built on top of that config. Is this the scenario you had in mind? To make that happen, become_leader() should set uncommitted_config_ to last_config_cloned, but it doesn't. I think we need to add it at this line:

NuRaft/src/raft_server.cxx

Line 1207 in 104a750

config_changing_ = true;

        config_changing_ = true;
        uncommitted_config_ = last_config_cloned;

That fixes the issue without any change to set_priority().

[Qian-Cheng-nju]

@greensky00 Thanks for the clarification. You’re right that the election config alone isn’t a problem. I’ve updated the PR with your suggested uncommitted_config_ assignment and replaced the original test with coverage for a priority change on top of an inherited, uncommitted membership change. The regression fails before the fix and passes afterward.

[greensky00]

Thanks!