Skip to main content

NOTICE_STREAM_LAG_CODE

Constant NOTICE_STREAM_LAG_CODE 

Source
pub const NOTICE_STREAM_LAG_CODE: i32 = -7;
Expand description

Synthesized notice code delivered in-band on the notice stream when its consumer fell behind the notice fan-out: the broadcast channel evicted the oldest notices, and this notice — carrying the dropped count in its message — is what the consumer sees in their place.

Negative, like the other client-synthesized notice codes; TWS itself only uses codes 0 and up.

The notice stream is how a stateful consumer receives the unrouted connection-status notices (1100 lost, 1101/1102 restored) it derives durable conclusions from, so a silent skip is not survivable: losing a 1101 voids every market-data request server-side yet leaves the client’s subscriptions looking healthy forever, and losing a restoration notice after a recorded 1100 holds every pending reopen forever. On receiving this notice the stream’s conclusions are unknown — any of them may rest on notices that were dropped — so the consumer must resynchronize rather than resume: treat recorded state as describing an unknown moment between the eviction and now, and re-derive it (a connection-state authority re-baselines its link state and re-establishes subscriptions). This is the notice-stream instance of SUBSCRIPTION_LAG_CODE, closing the step-1 leftover in plans/broadcast-lag-visibility.md (#779). The sync notice fan-out is unbounded and cannot lag.