#[non_exhaustive]pub enum SubscriptionEvent {
Activated {
item_count: usize,
field_count: usize,
command_fields: Option<CommandFields>,
},
Update(Box<ItemUpdate>),
EndOfSnapshot {
item_index: usize,
},
SnapshotCleared {
item_index: usize,
},
Overflow {
item_index: usize,
dropped_count: u64,
},
Reconfigured {
max_frequency: UpdateFrequency,
filtering: Filtering,
},
Deferred {
reason: String,
},
Rejected(ServerError),
Unsubscribed,
Undecodable {
detail: String,
},
}Expand description
Everything one subscription can tell you.
Delivered by Updates. #[non_exhaustive], so match with a trailing _
arm and a later version adding a variant will not break your build.
The ordinary shape of a subscription’s life is
Activated, then a run of
Updates — snapshot first if one was asked
for, real-time after — and finally either
Unsubscribed or
Rejected. After a session is replaced, a
second Activated arrives and the run starts over.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Activated
The subscription is live on the server and its shape is now known
[docs/spec/04-notifications.md §3.1, §3.2].
Arrives again whenever the subscription is re-created on a session that replaced a lost one, in which case every item’s state has been rebuilt from nothing.
Fields
field_count: usizeHow many fields the server resolved the field schema into. Every update carries exactly this many values.
command_fields: Option<CommandFields>Present exactly for SubscriptionMode::Command
subscriptions, which the server activates differently because it
must also say where the key and command fields are.
Update(Box<ItemUpdate>)
New values for one item [docs/spec/04-notifications.md §2].
The update carries the item’s complete state, not only what
changed, so every field is readable; ask
ItemUpdate::changed_fields what actually moved.
EndOfSnapshot
The snapshot of one item is complete; everything after this is a live
change [docs/spec/04-notifications.md §3.5].
Sent in DISTINCT and COMMAND modes. A MERGE snapshot is a single
update and gets no boundary marker; RAW has no snapshot at all.
SnapshotCleared
The server cleared one item’s snapshot
[docs/spec/04-notifications.md §3.6].
Drop the list, history or row set you accumulated for this item. The field values this crate tracks are deliberately not cleared, so that a delta arriving straight afterwards still decodes.
Overflow
The server dropped updates for one item, because of its own buffer
limits [docs/spec/04-notifications.md §3.7].
Those updates are gone; nothing can reconstruct them, and the item’s values now reflect only what survived. This is the protocol’s own way of surfacing loss rather than hiding it, and this crate passes it straight through.
It can only happen in RAW mode, for ADD/DELETE events in
COMMAND mode, and for subscriptions that asked for
MaxFrequency::Unfiltered.
Fields
Reconfigured
The subscription’s frequency configuration
[docs/spec/04-notifications.md §3.8].
Arrives once when the subscription starts — possibly before
Activated — and again after every
reconfiguration, even one that changed nothing.
Fields
max_frequency: UpdateFrequencyThe rate now in force.
Deferred
The subscription request could not be sent, and will be retried when the session next binds.
Not terminal, and not a refusal. The server never saw the request —
the connection was gone, or the transport rejected it — so it has no
opinion on your subscription yet. This crate keeps the subscription in
its desired set and re-issues it on the next connection, after which
Activated arrives as usual.
You do not have to do anything. It is surfaced because it means a real delay before data starts, and a subscription that seems slow to start should not be a mystery.
Rejected(ServerError)
The server refused the subscription, with a code from Appendix B
[docs/spec/05-error-codes.md §2].
Terminal: nothing else arrives on this stream, and the subscription is
not retried on a later session. Common causes are a bad item group
(code 21), a bad field schema (23), a mode the item does not allow
(24), and — in COMMAND mode — a schema with no key or no command
field (15, 16).
Contrast Deferred, where the request
never reached the server and is still coming.
Unsubscribed
The subscription ended [docs/spec/04-notifications.md §3.4].
Terminal: no further update for these items and fields will be sent.
Undecodable
A notification for this subscription could not be interpreted.
Never fatal and never silent: the stream keeps running, and the item state it refers to is whatever the last decodable update left. Seeing this repeatedly means this client and the server disagree about the subscription’s shape, which is worth reporting as a bug.
Implementations§
Source§impl SubscriptionEvent
impl SubscriptionEvent
Sourcepub const fn is_terminal(&self) -> bool
pub const fn is_terminal(&self) -> bool
Whether nothing further will arrive on this subscription’s stream.
Trait Implementations§
Source§impl Clone for SubscriptionEvent
impl Clone for SubscriptionEvent
Source§fn clone(&self) -> SubscriptionEvent
fn clone(&self) -> SubscriptionEvent
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more