The history of session S4040fce00115c0a5T5129274, until it is replaced by session Sb50bef2560eac1cbT3950716, is normal.
The high number of STREAMING_IN_PROGRESS requests may be due to a huge amount of pushed data against a short content-length setting in the Server configuration file (can you confirm?).

However, the replicated control request at 08:54:26,992 refers to subscriptions that were processed by the Server several seconds before;
this confirms that some delays occur in the client-server communication
(for instance, do you notice any CPU overload on the client side?).
If a similar delay had affected the rebind request at 10:39:50,264
this would explain the replacement of the session
(which is the setting for <session_timeout_millis> in the Server configuration file?).
Moreover, if a similar delay had affected the subsequent control requests,
this would explain the sync errors.

I'm afraid we need to identify the javascript error that occurred after the establishment of session Sb50bef2560eac1cbT3950716,
in order to understand what caused the new session not to start correctly.