Subscription recording moved from optimistic pre-send to ack-only. A subscribe that never reaches
the server therefore leaves no record at all, so subscribeAll has nothing to replay for it.
Previously the subscription was written to this.subscriptions before the send, so a subscribe
that failed in flight was still replayable on reconnect. Now the record is written only once the
server acknowledges.
Offline is the case where this bites: the errors raised when there is no connection are sorted into
neither branch of subscribe, and rememberSubscription returns early when there is no
connection, so nothing is recorded and nothing can be replayed.
Why this is being accepted rather than reverted
Ack-only recording is the more accurate record — optimistic recording writes down subscriptions
that may never exist server-side. The consuming application is being changed to re-subscribe its
own streams on reconnect, which removes the need for replay coverage of never-acknowledged
subscriptions.
This issue exists so the narrowing is on record as a deliberate change rather than an unexplained
behavioural difference.
Related
Socket.subscribe also ends in a terminal .catch returning undefined, so callers have no
failure signal at all. That is being addressed separately by making subscribe reject.
Subscription recording moved from optimistic pre-send to ack-only. A subscribe that never reaches
the server therefore leaves no record at all, so
subscribeAllhas nothing to replay for it.Previously the subscription was written to
this.subscriptionsbefore the send, so a subscribethat failed in flight was still replayable on reconnect. Now the record is written only once the
server acknowledges.
Offline is the case where this bites: the errors raised when there is no connection are sorted into
neither branch of
subscribe, andrememberSubscriptionreturns early when there is noconnection, so nothing is recorded and nothing can be replayed.
Why this is being accepted rather than reverted
Ack-only recording is the more accurate record — optimistic recording writes down subscriptions
that may never exist server-side. The consuming application is being changed to re-subscribe its
own streams on reconnect, which removes the need for replay coverage of never-acknowledged
subscriptions.
This issue exists so the narrowing is on record as a deliberate change rather than an unexplained
behavioural difference.
Related
Socket.subscribealso ends in a terminal.catchreturningundefined, so callers have nofailure signal at all. That is being addressed separately by making
subscribereject.