#[non_exhaustive]pub enum Continuity {
New,
Preserved,
Recovered {
requested_from: u64,
},
Replaced {
previous_session_id: Option<String>,
},
}Expand description
What a newly bound session means for state you built on the previous one.
This is the distinction ADR-0005 exists for. Read it as: may I keep what I
computed? — and Continuity::state_validity is that question asked
directly.
Debug redacts the previous session identifier for the reason given on
Connected; the field itself is public and unredacted.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
New
The first session of this client.
There is nothing this client preserved, which is not the same as
nothing being wrong: an application whose state outlived an earlier
client — rebuilt after Error::ReconnectExhausted, say — is holding
state derived from a session that no longer exists. That is why
Continuity::state_validity answers
Invalid here as it does for
Replaced.
Preserved
The same session, rebound over a fresh connection after a clean
handover — the server told the client to reconnect and guaranteed that
nothing was dropped in between
[docs/spec/02-session-lifecycle.md §4.4].
Every subscription is intact, server-side, with all its items and fields. Keep your state.
Recovered
The same session, resumed after an interruption the client recovered from.
Whether anything was actually missed is not known yet at this
point: the server answers separately, and this client reports the
answer as SessionEvent::Recovered immediately afterwards. Hold your
state and decide when Recovery::is_lossless says; this is the case
Continuity::state_validity reports as
Pending, rather than claiming a
preservation the server has not confirmed.
Fields
Replaced
A new session replaced one that was lost.
Nothing carries over: the notification count restarts at zero and every
subscription is created again from scratch
[docs/spec/02-session-lifecycle.md §6.1]. Any state you derived from
the previous session is stale — discard it and rebuild from the
snapshots that follow.
Implementations§
Source§impl Continuity
impl Continuity
Sourcepub const fn state_validity(&self) -> StateValidity
pub const fn state_validity(&self) -> StateValidity
Whether state derived from an earlier session may still be used.
This replaces a boolean that could not tell the truth. Two of the four cases do not answer yes or no:
| Continuity | Validity | Why |
|---|---|---|
Preserved | Valid | the same session, nothing dropped |
Recovered | Pending | the same session, but whether a gap opened is not known until the next event |
Replaced | Invalid | a different session; the notification count restarts |
New | Invalid | there is no earlier session of this client to have preserved anything |
New answering Invalid is the case worth explaining. It is not that
something was lost — nothing was — but that nothing was kept, and
an application whose state outlives its client (rebuilt after
Error::ReconnectExhausted, say) is asking the same question and
deserves the same answer. Reporting a first session as “preserved”
would tell it to keep a book built on a session that no longer exists.
§Examples
use lightstreamer_rs::{Continuity, StateValidity};
let recovering = Continuity::Recovered { requested_from: 42 };
assert_eq!(recovering.state_validity(), StateValidity::Pending);
assert_eq!(Continuity::New.state_validity(), StateValidity::Invalid);Trait Implementations§
Source§impl Clone for Continuity
impl Clone for Continuity
Source§fn clone(&self) -> Continuity
fn clone(&self) -> Continuity
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more