Skip to main content

SignalSink

opssignal_core::sink

Trait SignalSink 

Source 
pub trait SignalSink: Send + Sync {
    // Required methods
    fn record(&self, signal: &Signal) -> Result<(), SignalError>;
    fn complete(
        &self,
        signal: &Signal,
        result: &DeliveryResult,
    ) -> Result<(), SignalError>;

    // Provided method
    fn provider_outcome(
        &self,
        _signal: &Signal,
        _outcome: &ProviderOutcome,
    ) -> Result<(), SignalError> { ... }
}
Expand description

A sink is a write-only side effect of the pipeline — not a queryable API the SDK exposes. Querying, dashboards, and aggregation are explicitly out of scope here; that’s the hosted control plane’s job, reading from the same store OSS users already populate.

Each signal is written twice: record before delivery starts, with status pending, and complete once the outcome is known. A signal whose process exits mid-delivery therefore stays visible as pending instead of vanishing.

Required Methods§

Source

fn record(&self, signal: &Signal) -> Result<(), SignalError>

Stores a signal that is about to be delivered.

Source

fn complete( &self, signal: &Signal, result: &DeliveryResult, ) -> Result<(), SignalError>

Stores the delivery outcome, including result.deliveries. Must also work when record failed or never ran for this signal, so the outcome is never lost.

Provided Methods§

Source

fn provider_outcome( &self, _signal: &Signal, _outcome: &ProviderOutcome, ) -> Result<(), SignalError>

Stores one provider’s outcome while delivery is still running: pending before its first attempt, then delivered or failed. A fan-out cut short by a timeout or an exit then still shows which providers already have the signal. Sinks that only keep the overall outcome can leave this as is.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§