You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an open issue addressing this request? If it does, please add a "+1" reaction to the
existing issue, otherwise proceed to step 2.
No.
Describe the feature you are requesting, as well as the possible use case(s) for it.
The implementation of the WS adapter in #1625 pointed out a different problem: What happens if the connection is closed and Unsubscribe fails? Since the connection is closed, there is no way for the client to call Unsubscribe anymore. And in the NATS (the default) implementation of the PubSub, trying to subscribe returns an error if the subscription already exists, leaving the client in the limbo state - it can't unsubscribe (the connection is broken) and there is no way to subscribe (the entry exists due to unsuccessful previous unsubscribe attempt).
The most straightforward workaround for this problem is to adopt the MQTT approach - Calling subscribe for the client that's already subscribed results in unsubscribe the old entry and creating a new subscription - effectively replacing the old subscription with the new one.
Indicate the importance of this feature to you (must-have, should-have, nice-to-have).
This is a must-have because for protocols that support subscribing we can't rely on a connection to never break or calling Unsubscribe to never fail.
The text was updated successfully, but these errors were encountered:
FEATURE REQUEST
existing issue, otherwise proceed to step 2.
No.
The implementation of the WS adapter in #1625 pointed out a different problem: What happens if the connection is closed and
Unsubscribe
fails? Since the connection is closed, there is no way for the client to callUnsubscribe
anymore. And in the NATS (the default) implementation of thePubSub
, trying to subscribe returns an error if the subscription already exists, leaving the client in the limbo state - it can't unsubscribe (the connection is broken) and there is no way to subscribe (the entry exists due to unsuccessful previous unsubscribe attempt).The most straightforward workaround for this problem is to adopt the MQTT approach - Calling subscribe for the client that's already subscribed results in unsubscribe the old entry and creating a new subscription - effectively replacing the old subscription with the new one.
This is a must-have because for protocols that support subscribing we can't rely on a connection to never break or calling
Unsubscribe
to never fail.The text was updated successfully, but these errors were encountered: