Enum LineOutcome 

#[non_exhaustive]
pub enum LineOutcome {
    Sent,
    NoStdin,
    NotWritten {
        reason: String,
    },
}

What happened when the shepherd tried to write one line to a sheep’s stdin.

#[non_exhaustive]: a future outcome — a sheep refused because its pipe is backed up, say — must not need a protocol version bump (IR-20).

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

Sent

The line was written to the pipe and flushed.

Says the bytes left the shepherd, not that the app read them. A pipe holds 64 KiB before it blocks, so a short line to an app that never reads its stdin is Sent — which is honest, because there is nothing on this path that could tell the difference and a supervisor inventing one would be guessing.

NoStdin

The sheep has no stdin pipe: its config does not set stdin = true, or it is not running.

One outcome for two causes, deliberately. The row is read to answer “why did my line not arrive”, and both answers are “there is no pipe here”; splitting them would put the operator in front of a distinction with the same fix behind it. A sheep that is not running is visible as such in shep flock, which is where that question belongs.

NotWritten

The shepherd had a pipe and did not confirm a write to it; carries why.

Three shapes reach it: the write failed (the far end is gone — normally the app exiting between the lookup and the write), the line arrived to find the sheep’s queue already full, or the write did not finish inside the shepherd’s own bound. The reason names which, because the operator’s next move differs.

The last shape does not promise the line was never written

“Did not confirm”, not “could not write”, and the difference is the operator’s whole decision about retrying. A write that timed out is a write the shepherd stopped WAITING for: the bytes may be part-written into a pipe the app is not draining, and they land in full the moment it does. There is no way to take them back — abandoning a write halfway would leave a partial line in the pipe, which is worse than a slow one.

What the shepherd does do is drop a line still QUEUED behind that one once its caller has given up, so retrying a sendline cannot pile duplicates up behind a wedged pipe and deliver them together later. The first line of a retry sequence is the one that can still arrive late; treat a retry as a second command, not a repeat of the first.

Fields

reason: String

What went wrong, in plain English.

Trait Implementations

impl Clone for LineOutcome

fn clone(&self) -> LineOutcome

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for LineOutcome

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for LineOutcome

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Eq for LineOutcome

impl PartialEq for LineOutcome

fn eq(&self, other: &LineOutcome) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for LineOutcome

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for LineOutcome