#[non_exhaustive]pub enum Unusable {
LostReadCount,
LostWriteCount,
IncompleteOutput,
}Expand description
Why a core became unusable: a transport moved bytes and their count was lost, so the core’s position no longer matches the transport’s (ADR-041 § 6).
No inspection recovers it — 0x00 is valid tensor data — so the state is named and
reported rather than guessed at. “Probably still fine” is not a state.
§Examples
use hurray_io::stream::StreamReaderCore;
use hurray_io::Error;
let mut core = StreamReaderCore::new();
core.mark_unusable();
assert!(matches!(core.step(), Err(Error::CoreUnusable(_))));Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
LostReadCount
A read moved bytes into the core’s destination and the count never arrived. Only this core’s position is lost; the transport is untouched.
LostWriteCount
A write put an unknown number of payload bytes on the wire, so the position is
unknown. Narrower than Self::IncompleteOutput, which is a known-incomplete
item: a stream cannot be un-sent, so the sink is poisoned too — the reader at the
far end will see a truncated item, and a fresh writer over the same connection is
not a recovery.
IncompleteOutput
An item was begun and cannot be completed, so the output is incomplete. The count
is known, unlike Self::LostWriteCount; what is lost is the ability to produce
a conforming output, because a forward-only writer has no way back to the item’s
start (§ 6b).