Non-atomic vote persistence in handleRequestVoteRequest

[Qian-Cheng-nju]

Describe the bug

handleRequestVoteRequest() does not check the return value of metaStorage.setVotedFor() at NodeImpl.java#L1860. If the disk write fails but the process survives, the response is still granted=true because the in-memory votedId was already set at L1859 before the write. After restart the vote is lost, allowing a different candidate to be granted in the same term.

This is the only call site that uses setVotedFor() alone. All other call sites use setTermAndVotedFor().

Expected behavior

A node should vote for at most one candidate per term, even after a write failure and restart.

Actual behavior

If setVotedFor() fails (I/O error), the response is still granted=true. After restart, the node grants a vote to a different candidate in the same term.

Steps to reproduce

See #1242. The test makes the meta directory read-only before setVotedFor() is called, causing a real I/O failure through the full reportIOError() → node.onError() path.

Minimal yet complete reproducer code (or GitHub URL to code)

See #1242.

Environment

• SOFAJRaft version: master
• JVM version: 21
• OS version: Linux

[killme2008]

Good catch!

It should verify the result returned by setVotedFor.

I reviewed PR #1242, and it includes more than just this fix. Could you open a separate PR that only fixes this issue and adds a test?

[Qian-Cheng-nju]

@killme2008 Thanks for the review! I've opened a separate PR with just the fix and test: #1243.

The fix checks the return value of setVotedFor() in handleRequestVoteRequest() — if it fails, the in-memory votedId is rolled back to empty so the response is granted=false.