#[non_exhaustive]pub enum Response {
Show 31 variants
Pong,
Flock(Vec<ProcessInfo>),
Described(Vec<ProcessInfo>),
Started(Vec<ProcessInfo>),
Added(Vec<ProcessInfo>),
Drifted(Vec<SheepDrift>),
Applied(Vec<SheepApplied>),
SheepConfig(Box<SheepConfigView>),
SheepEnvSet {
name: String,
key: String,
},
SheepFieldSet {
name: String,
key: String,
pending: bool,
},
DogConfigSet {
name: String,
},
SecretsPut {
accepted: u32,
},
Stopped(Vec<ProcessInfo>),
Restarted {
accepted: Vec<ProcessInfo>,
refused: Vec<SheepRefusal>,
},
Reloading {
accepted: Vec<ProcessInfo>,
refused: Vec<SheepRefusal>,
},
Scaled(Vec<ProcessInfo>),
SmitPainted(Vec<ProcessInfo>),
Deleted(Vec<u32>),
Reopened(Vec<ProcessInfo>),
Flushed(Vec<ProcessInfo>),
Triggered(Vec<ActionReply>),
Signalled(Vec<SignalReply>),
SentLine(Vec<LineReply>),
RollSaved {
path: String,
apps: u32,
},
Mustered(Vec<ProcessInfo>),
DogSection {
toml: DogSectionToml,
},
DogStarted(ProcessInfo),
DogStaleness {
stale: Vec<String>,
pending: Vec<String>,
},
HandoverFitness {
refusal: Option<String>,
},
Subscribed,
ShuttingDown,
}Expand description
One RPC response (pairs with Request variants)
Ten variants carry a bare Vec<ProcessInfo>. Do not collapse them into
one: each names which request it answers, which is what lets a variant
diverge without a protocol bump. Reloading already means an acceptance
rather than a result, Scaled only the survivors of a scale-down, and
Mustered every sheep of every restored app rather than what this call
started.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Pong
Answer to Ping
Flock(Vec<ProcessInfo>)
Answer to ListFlock
Described(Vec<ProcessInfo>)
Answer to Describe
Started(Vec<ProcessInfo>)
Answer to Start
Added(Vec<ProcessInfo>)
Answer to Add: one row per app the request named, registered and
spawning nothing.
A row here can still be Online: Add is idempotent by name, so the
reply describes the membership the request leaves behind.
Drifted(Vec<SheepDrift>)
Answer to ConfigDrift: one entry per app that is registered under a
config different from the one asked about, and no entry for anything
else. An empty vector means every app asked about either matches or
is not registered at all.
Applied(Vec<SheepApplied>)
Answer to ApplyConfig: one entry per app the request named, in the
order it named them, the refused and the unchanged included.
Complete where Self::Drifted is filtered: an app missing from
“what did you do to each of these” looks like one the daemon dropped.
SheepConfig(Box<SheepConfigView>)
Answer to SheepConfig: one sheep’s config with env emptied and
its keys listed beside it.
Boxed, and the only variant here that is. This one carries a whole
AppConfig, which is several times the size of anything else in
the enum, and a Response is inside a Reply which is inside a
ServerFrame: without the box,
every frame the daemon sends costs the largest config’s worth of
stack for a variant almost none of them use.
The enum-level #[allow(clippy::large_enum_variant)] below does not
cover it, and the difference is the point of that allow’s own
argument: boxing DogStarted would be a source break for every
Response::DogStarted(info) in and out of this workspace, where
this variant has never shipped and so breaks nobody.
Box<T> serializes exactly as T, so the wire bytes and the pinned
fixtures are untouched.
SheepEnvSet
Answer to SetSheepEnv: the key that was set or removed.
Never the value, and never the resulting env map. This reply exists
to confirm which key moved, and echoing what was just written back
down a socket would undo the whole point of SheepConfig withholding
it (IR-41).
SheepFieldSet
Answer to SetSheepField: which field moved, and whether the
running child has it.
Not Self::Applied’s three lists; the difference is the
request’s own shape. applied, pending and refused exist
because ApplyConfig carries N apps of M fields, so a caller cannot
otherwise tell which field went where or that one app of eleven was
refused. This request carries one field of one sheep, so refused
would be a second way to say no beside the Err arm (a client
checking only the Err would silently swallow the other), and the
two lists collapse to the one bit that is left.
That bit is not redundant with the field’s own
ApplyGroup, which the caller already
knows. It is the daemon’s answer about state a caller cannot see:
autostart is NextSpawn and yet reports as in force, because it
is read at muster rather than at a spawn, and a Live field whose
config subset will not normalize on its own parks instead of
applying.
Fields
pending: booltrue when the running child does not have the value yet and
shep reload <name> is what promotes it. A client rendering
this says so, the same rule SheepApplied::pending carries.
DogConfigSet
Answer to SetDogConfig: the section was written and the topic
published.
SecretsPut
Answer to Request::PutSecrets: how many entries were stored.
Stopped(Vec<ProcessInfo>)
Answer to Stop
Restarted
Answer to Restart: the sheep that were restarted, one row each.
When the reply arrives depends on how many sheep matched. One sheep is answered as soon as its respawn is issued. Two or more are restarted in dependency order, and the daemon holds each stage until the apps a later stage waits on are back, so the reply arrives no sooner than the last stage’s respawns and the rows are stitched from one answer per stage. A client asking for a budget sizes it for the whole walk, not for one respawn.
Fields
accepted: Vec<ProcessInfo>The sheep the restart reached, one row each.
A row is not a promise the process is up. A respawn that could
not exec is an errored row here rather than an entry in
refused below: the sheep was reached and the restart was not
refused, it is the child that failed.
refused: Vec<SheepRefusal>The apps the walk could not restart, empty when it restarted every one it named.
Only a walk fills this. A selector matching one app is refused
whole, as the Err arm, so a client reading a single-target
restart never sees a row here.
Reloading
Answer to Reload: acceptances, not results.
One instance costs a readiness wait plus a drain, so a clustered app
outlasts any deadline a client may ask for. Every row is therefore the
sheep as it stood when its own reload was accepted, and the swaps
report themselves on the bus (process.reload, process.reloaded,
process.reload_abandoned). A matched sheep with nothing to replace
is listed as the no-op success it is.
When the reply arrives depends on how many sheep matched. One sheep is answered as soon as its reload is accepted. Two or more are reloaded in dependency order, and the daemon holds each stage until the swaps of the apps a later stage waits on have landed, so the reply arrives no sooner than the last stage’s acceptance and the rows are stitched from one acceptance per stage. A client asking for a budget sizes it for the whole walk, not for one acceptance.
Fields
accepted: Vec<ProcessInfo>The sheep whose reloads were accepted, one row each.
refused: Vec<SheepRefusal>The apps the walk could not reload, empty when it reloaded every one it named.
Only a walk fills this. A selector matching one app is refused
whole, as the Err arm, so a client reading a single-target
reload never sees a row here.
Scaled(Vec<ProcessInfo>)
Answer to Scale: the app’s instances that will remain, one row each,
ordered by sort_flock. Every row shares one name, so that is slot
order with the id breaking a tie.
Scaling down, the departing instances are absent even though their
kill ladders are still running; they report themselves on the bus as
process.delete.
SmitPainted(Vec<ProcessInfo>)
Answer to SetSmit: every instance of the named sheep, one row each,
carrying the smit as it now stands.
Deleted(Vec<u32>)
Answer to Delete: ids removed
Reopened(Vec<ProcessInfo>)
Answer to Reopen: every matched sheep, running or not. A sheep with
no live log pump has nothing to reopen and is reported as a success,
so this carries the same matches Describe would.
Flushed(Vec<ProcessInfo>)
Answer to Flush: one row per matched sheep, running or not, exactly
as Self::Reopened.
One row per sheep, not per file emptied: several sheep can share one log path, and the daemon truncates each distinct path once.
Triggered(Vec<ActionReply>)
Answer to Trigger: one ActionReply row per matched sheep, rather
than a flock listing, since ProcessInfo has nowhere to hold a reply
body.
Signalled(Vec<SignalReply>)
Answer to Signal: one SignalReply row per matched sheep.
Not a flock listing: ProcessInfo has nowhere to hold a per-sheep
outcome.
SentLine(Vec<LineReply>)
Answer to SendLine: one LineReply row per matched sheep.
RollSaved
Answer to SaveRoll
Fields
Mustered(Vec<ProcessInfo>)
Answer to Muster: every sheep of every app the roll restored, not
only the ones this call spawned.
Assembling a flock that is already assembled starts nothing, so a listing of what this call spawned would be indistinguishable from an empty roll.
DogSection
Answer to DogConfig: the dog’s own section, rendered back to TOML.
toml is DogSectionToml, whose manual Debug keeps the webhook
credentials this text carries out of a {:?}-formatted Response.
Fields
toml: DogSectionTomlThe [dog.<name>] table as TOML text, empty when the file has
no such section
DogStarted(ProcessInfo)
Answer to EnableDog: the dog as it stands now
DogStaleness
Answer to DogStaleness: this daemon’s own handshake record, split
into the dogs it has given up on and the dogs it is still waiting on.
Two lists because they answer two questions. stale is a finding;
pending is a reason to ask again, since a reading taken now would
be a guess about them.
Names only: two builds differing only in the protocol they speak report the same crate version.
Fields
HandoverFitness
Answer to HandoverFitness: None when the whole flock can be
carried across a daemon handover, and otherwise the sentence saying
which sheep cannot be and why.
A rendered sentence rather than a structured reason: the set of things a handover cannot carry keeps changing, and the client only prints it.
Subscribed
Answer to Subscribe
ShuttingDown
Answer to KillDaemon