[DB-2219]: Removed quorum-based fencing

[sakno]

Changed: Removed quorum-based fencing

[linear-code]

DB-2219

[qodo-code-review]

PR Summary by Qodo

Wait for all fencing responses before leader appointment

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Waits for every data-plane fencing request to settle before appointing a leader.
• Prevents quorum cancellation from interrupting follower flush completion and risking inconsistent
 state.

Diagram

graph TD
  A["Appointment needed"] --> B["Bump epoch"] --> C["Fence all nodes"] --> D["Wait for completion"] --> E{"Quorum reached?"}
  E -->|Yes| F["Select candidate"] --> G["Appoint leader"]
  E -->|No| H["Reuse epoch"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Acknowledge fencing only after durable flush

• ➕ Preserves quorum-based appointment latency.
• ➕ Enforces the durability guarantee at the data-plane boundary.
• ➖ Requires broader data-plane and protocol changes.
• ➖ Increases implementation and regression risk for an urgent consistency fix.

Recommendation: Use the PR's localized wait-for-all approach as the immediate correctness fix. If fencing latency becomes significant, consider making data-plane acknowledgements flush-aware before safely restoring quorum-based completion.

Files changed (1) +12 / -18

Bug fix (1) +12 / -18

RaftKontroller.Appointment.csWait for all fencing operations before evaluating quorum +12/-18

Wait for all fencing operations before evaluating quorum

• Removes the linked cancellation token that stopped outstanding fencing requests once quorum responded. The appointment round now collects every successful response or failure before checking quorum, preventing unfinished follower flushes from overlapping leader appointment.

src/KurrentDB.KontrolPlane/KontrolPlane/Raft/RaftKontroller.Appointment.cs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[timothycoleman]

We thought it'd be neat to proceed with the appointment as soon as quorum nodes have responded.

This reverts that optimisation and so we wait for any nodes that respond within the timeout.

It matters because followers ack before flush, so it is possible (though unlikely) for a write to be present on the leader (on disk) and one follower (in memory), then for that follower to be restarted (losing the write) and back in time to participate in an appointment before the leader was able to replicate that write to the other follower, then for the two followers to be the ones who respond to the appointment fence first.