Class MassiveStreamSubscriptionException

Namespace

MassiveDotNet.WebSocket

Assembly

MassiveDotNet.WebSocket.dll

The server did not acknowledge every subscription requested.

public sealed class MassiveStreamSubscriptionException : MassiveStreamException, ISerializable

Inheritance

object

Exception

MassiveStreamException

MassiveStreamSubscriptionException

Implements

ISerializable

Inherited Members

Exception.GetBaseException()

Exception.GetType()

Exception.ToString()

Exception.Data

Exception.HelpLink

Exception.HResult

Exception.InnerException

Exception.Message

Exception.Source

Exception.StackTrace

Exception.TargetSite

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.ReferenceEquals(object, object)

Remarks

The server answers one status: success per accepted pair and says nothing about a pair it does not recognise, so a shortfall is the only evidence that something was dropped. It throws rather than continuing because a subscription that silently does not exist is indistinguishable from a quiet market (D-W2).

A pair can also be refused out loud, and then the server's own words are the better evidence: see ServerMessage and D37.

It reaches a caller two ways. SubscribeAsync throws it, because a caller is awaiting that request. A reconnect's replay instead raises it through SubscriptionsLost, because nobody is awaiting a replay -- the same evidence, delivered as a signal rather than a throw (D33).

Constructors

MassiveStreamSubscriptionException(string, int, string?)

Creates the exception.

public MassiveStreamSubscriptionException(string parameters, int unacknowledged, string? serverMessage = null)

Parameters

parameters string

The subscription parameter that was sent.

unacknowledged int

How many pairs went unacknowledged.

serverMessage string

The server's own reason, verbatim, or null when it gave none.

Properties

Parameters

The subscription parameter this exception is about, such as T.AAPL,T.MSFT.

public string Parameters { get; }

Property Value

string

Remarks

Retained rather than left only inside Message so a handler can act on it -- re-subscribe, or report which topics went dark -- without parsing prose. D-W2's own argument for counting acknowledgements rather than reading the server's wording applies to this SDK's wording too: a message is the part of a contract nobody versions.

Raised out-of-band through SubscriptionsLost, this names only the pairs a reconnect's replay failed to restore, not everything that was replayed.

ServerMessage

What the server said when it refused the request, verbatim, or null when it said nothing at all.

public string? ServerMessage { get; }

Property Value

string

Remarks

Both cases are real and they mean different things (D37). A refused subscribe is answered -- not authorized, for a topic the key's plan does not include -- while an unrecognised topic code is dropped in silence, which is what leaves Unacknowledged as the only evidence available. Message says whichever happened.

The words are the server's and are reported rather than categorised: error covers unrelated failures distinguished only by prose, exactly as auth_failed does for ServerMessage (D-W6), and a category invented from one observation is one that drifts. A consumer who wants to handle a refusal separately from a silent drop filters on this being non-null.

Unacknowledged

How many requested pairs went unacknowledged. A caller sees this as evidence, not detail: a non-zero count means at least one topic.ticker pair in the request was silently dropped by the server rather than accepted, so the subscription is incomplete and the missing pairs will never deliver data until the request is corrected and retried.

public int Unacknowledged { get; }

Property Value

int