#[non_exhaustive]pub enum Error {
NotLeader {
leader: Option<NodeId>,
},
Storage {
context: &'static str,
detail: String,
},
Encoding {
context: &'static str,
detail: String,
},
ConfigInProgress,
}Expand description
Everything that can go wrong while driving a RaftNode.
The type is #[non_exhaustive]: later phases (persistence, snapshots) add
variants without a major bump, so a match over it must include a wildcard
arm.
§Examples
use raft_io::Error;
// A proposal sent to a follower is rejected with a hint to the leader.
let err = Error::NotLeader { leader: Some(3) };
assert_eq!(err.to_string(), "not the leader; current leader is node 3");Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
NotLeader
A client proposal was made to a node that is not the leader.
Only the leader may accept proposals. leader carries the node’s best
knowledge of who the current leader is, so the caller can redirect the
request; it is None when no leader is known (for example during an
election). This is a normal, recoverable condition — retry against the
indicated leader.
Storage
A RaftLog backend operation failed.
The in-memory log never produces this, but a durable backend (the
wal-db-backed log arriving in v0.4) can fail to read, append, or
flush. context names the operation that was attempted (for example
"append entries" or "sync log") so the message is actionable, and
detail carries the backend’s own description. The caller should treat
a storage failure on the durability path as fatal to the node: a node
that cannot persist its state must not continue participating.
Fields
Encoding
A message failed to encode to or decode from its wire form.
Produced by the framing module (the framing feature) when
pack-io cannot serialize a message or a received byte string does not
decode into a valid one. context names the operation and detail
carries the codec’s description. A decode failure is not fatal — the
transport should drop the malformed message and carry on, exactly as Raft
tolerates a lost one.
Fields
ConfigInProgress
A membership change was requested while a previous one is still in flight.
Raft changes the configuration one server at a time, and the leader must not begin a new change until the previous configuration entry has committed. Retry once the in-flight change completes. This is a routine, retryable condition.
Implementations§
Source§impl Error
impl Error
Sourcepub fn storage(context: &'static str, source: impl Display) -> Self
pub fn storage(context: &'static str, source: impl Display) -> Self
Builds a Storage error from any displayable backend
error.
Backends implementing RaftLog use this to map their
own error type into the crate’s error without naming its fields.
§Examples
use raft_io::Error;
let io = std::io::Error::new(std::io::ErrorKind::Other, "disk full");
let err = Error::storage("append entries", io);
assert!(err.to_string().contains("disk full"));Trait Implementations§
Source§impl Error for Error
impl Error for Error
1.30.0 · Source§fn source(&self) -> Option<&(dyn Error + 'static)>
fn source(&self) -> Option<&(dyn Error + 'static)>
1.0.0 · Source§fn description(&self) -> &str
fn description(&self) -> &str
use the Display impl or to_string()
Source§impl ForgeError for Error
impl ForgeError for Error
Source§fn is_retryable(&self) -> bool
fn is_retryable(&self) -> bool
A NotLeader rejection is retryable against the indicated leader and a
ConfigInProgress rejection is retryable once the change completes; a
storage failure on the durability path is not.
Source§fn is_fatal(&self) -> bool
fn is_fatal(&self) -> bool
A storage failure means the node can no longer guarantee durability and
should stop; a NotLeader rejection is a routine redirect.