After fdb25ca05dc5522ec82b6ad70ea4780d05f294dc, we removed the forwarding of errors from ws of a Connection to NotificationStream. This caused a set of problems with users trying to re-subscribe when a Subscription failed. In particular, since the connection error was forwarded before the catch close in the connect function inside notificationStream method, the connection object was not cleanly closed and it started reconnecting without control. Furthermore, it was impossible to invalidate the connection inside the connectionPool because the new connection was created before the clean-up function in the error handler (the error handler cannot be registered before the one that fire the initial error).
In future releases, we should spend time to rethink once again the process of connection control in our API.
After fdb25ca05dc5522ec82b6ad70ea4780d05f294dc, we removed the forwarding of errors from
wsof aConnectiontoNotificationStream. This caused a set of problems with users trying to re-subscribe when a Subscription failed. In particular, since the connection error was forwarded before thecatchclose in theconnectfunction insidenotificationStreammethod, the connection object was not cleanly closed and it started reconnecting without control. Furthermore, it was impossible to invalidate the connection inside theconnectionPoolbecause the new connection was created before the clean-up function in the error handler (the error handler cannot be registered before the one that fire the initial error).In future releases, we should spend time to rethink once again the process of connection control in our API.