Struct RemoteSink 

pub struct RemoteSink { /* private fields */ }

A fenced door for a remote watch loop’s pushes.

Created by the generated remote_sink() after the source is installed, it remembers which source that was. apply installs the document and reloads — unless the source has since been replaced, in which case it refuses: a watch loop serving yesterday’s store cannot overwrite today’s, by construction rather than by the old documentation’s request to please stop the loop first.

Cheap to clone; each wiring of a watch loop should take its own — once, where the loop starts. A sink taken per delivery reads the generation of that moment and fences nothing.

Implementations

impl RemoteSink

pub fn status(&self) -> RemoteStatus

How the fetches from the store behind this sink have gone.

The door a #[dynamic_config] type has to its RemoteStatus: the slot itself is generated private, and a sink is the public handle on it — which is also where the question belongs, since a sink is what a watch loop holds.

Taking a sink only to read this is fine and costs an atomic load: the generation a sink captures fences apply and nothing else. A loop that will deliver documents still takes its own, once, where it starts.

let status = DbConfig::remote_sink().status();

if status.reachable() == Some(false) {
    eprintln!("the store has stopped answering");
}

With the telemetry feature, Exposition::add_remote renders the same status as Prometheus text; see the telemetry module. The example above stays feature-free on purpose, because this method is not.

pub fn failed(&self, error: &Error)

Reports an attempt to reach the store that came back with nothing.

A watch loop is the half of a store this crate cannot see. apply records a delivery, so a working watch keeps RemoteStatus current — but a loop whose stream broke, whose blocking query is erroring or whose credential was refused delivers nothing, and would otherwise say nothing: reachable would report the last delivery rather than the last attempt, and a store that stopped answering an hour ago would look healthy until something called refresh.

What it moves is deliberately narrow — the failure streak and the last failure, and nothing else. fetches, last_fetch and last_fetch_duration are left alone, so dynamic_config_remote_last_fetch_seconds keeps ageing while dynamic_config_remote_up goes to zero, which is the pair an alert wants. The stored document is untouched: a failed attempt is no reason to stop serving what the last good one produced.

Fenced on the sink’s generation exactly as apply is, so a loop still winding down after its source was replaced cannot charge its failures to the replacement. A stale report is dropped silently, and there is nothing to handle: a loop must never have to deal with a failure to report a failure.

The error’s kind and key path are recorded and nothing else — a store’s address never enters a RemoteStatus, for the reason its own documentation gives.

pub fn apply(&self, document: Fetched) -> Result<(), Error>

Installs a document the watch pushed, and reloads.

Everything a file change would do happens here too — validation, the reload hooks, the cache — because it is the same code path, reached with a document instead of a filesystem event. A failure leaves the previous snapshot serving.

Errors

If the source has been replaced since this sink was created — checked before the reload and again after it, because a replacement can land while the reload runs — or if the resulting configuration does not load or validate.

Trait Implementations

impl Clone for RemoteSink

fn clone(&self) -> RemoteSink

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for RemoteSink

impl Debug for RemoteSink

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

Formats the value using the given formatter.