WebSocketSubject cannot be retried.

[benlesh]

RxJS version: 5.0.0-beta.2

Code to reproduce:

let socket = new WebSocketSubject('ws://badurlhere');

socket.retryWhen((errs) => errs.switchMap(() => Observable.timer(1000))
  .subscribe(::console.log);

Expected behavior:

connection fails and then retries once a second.

Actual behavior:

connection fails and then UnsubscriptionError is thrown, subsequent subscriptions do not work

Additional information:

This apparently has to do with some changes to Subject and unsubscription error handling. I'm not sure though. We should definitely add some tests around this scenario, because it's important. WebSocketSubject was supposed to be reusable.

I found this will trying out the multiplex method in production for the first time. :\ Bummer.

[rudolf]

I'm going to have a stab at this, I think I've identified the cause, but I'll write a failing test case to isolate it.

[rudolf]

I created a failing test case and a fix:
rudolf@9fd31cc

When I apply the fix to my own test environment it solves the problem, but the test still fails for some reason. Any ideas?

The problem is each time a multiplex subject unsubscribes, it sends the unsub message to announce this to the server. If, however, the underlying socket closes, the multiplex subject still tries to send it's unsub message over an already unsubscribed subject which throws an UnsubscriptionError.

The current fix check's the underlying socket's ready state with self.socket.readyState < 3 before sending an unsub message, but it might also be possible to check self.isUnsubscribed.

[fs123]

It looks, that the bug does no longer exists since beta 8. See added test in PR 1738 above.

[benlesh]

I created a failing test case and a fix: skaapgif@9fd31cc

@skaapgif did you already PR your fix and test for the unsub message?

[benlesh]

Closed by #1738

[rudolf]

I was still awaiting feedback, but @fs123's test is very similar and more thorough. I was able to reproduce the error without calling retry(1) though.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.