Struct SubscriptionSnapshot 

pub struct SubscriptionSnapshot { /* private fields */ }

A point-in-time view of a registered handler, produced by Subscription::load.

One load() pairs the handler’s committed checkpoint with the stream frontier, so every accessor below is synchronous and infallible — a consumer reading several of them pays one round-trip, not one per question. Nothing is cached: a fresh load() always reflects the latest committed state.

The checkpoint is decoded eagerly during load() (obix knows the handler job’s state type, so there is no reason to defer it to the caller), which is why these accessors cannot fail.

Implementations

impl SubscriptionSnapshot

pub fn checkpoint(&self) -> EventSequence

The handler’s committed checkpoint: every persistent event with a sequence at or below this has been handled and its effects committed (semantics 1). A handler that has never checkpointed reads as EventSequence::BEGIN (semantics 4).

pub fn frontier(&self) -> EventSequence

The stream frontier as of this load — the highest sequence the outbox had handed out (semantics 2).

pub fn stream_status(&self) -> SubscriptionStreamStatus

The { checkpoint, frontier } pair.

pub fn lag(&self) -> u64

How far the handler trails the frontier, saturating at zero.

pub fn is_caught_up(&self) -> bool

Whether the checkpoint has reached the frontier.

pub fn job_status(&self) -> JobStatus

Runtime status of the job hosting this handler.

A resident handler job stays Running; a terminal status means the handler is no longer consuming, which is the case Subscription::await_caught_up reports as a timeout rather than a hang.

pub fn last_error(&self) -> Option<&str>

The handler’s most recent failure, if it has ever failed an attempt.

This is the wedged-vs-slow signal. obix registers handlers to retry indefinitely, so a handler crash-looping on a poison event never reaches a terminal state: job_status keeps reporting Pending/Running while the checkpoint sits frozen. A lagging handler with Some here — especially with attempt climbing across successive loads — is stuck on this error, not merely backlogged.

None means no attempt has ever failed. A stale Some from an earlier, since-recovered failure is possible, which is why the pair with a frozen checkpoint (or a rising attempt) is what diagnoses.

pub fn attempt(&self) -> Option<u32>

The current attempt number — Some only while the job has a live execution row. Rising across loads means the handler is retrying; see last_error.

pub fn job(&self) -> &JobSnapshot

The underlying job snapshot, for callers that want the job’s own accessors (next run, queue id, config, return value).