share / sharedb / 1387

97%

master: 97%

Pull #358

travis-ci

Only allow a single subscribe/unsubscribe request to be in-flight

This change is a rework of our subscribe/unsubscribe logic. At the
moment, subscribe and unsubscribe messages are handled completely
separately, which means that we can hit race conditions when
simultaneous subscribe and unsubscribe requests are submitted.

This currently manifests itself in this bug:

  1. `subscribe()`
  2. `unsubscribe()` synchronously (ie before receiving the `subscribe`
     response
  3. Expect to finish unsubscribed. Indeed, `Doc` claims that I'm
     unsubscribed, but actually - because subscribe happens to take a
     bit longer on the server - I'm really still subscribed

This change reworks subscribe and unsubscribe requests into a queue:

  - there may only ever be a single in-flight subscribe or unsubscribe
    request
  - other requests are queued and only submitted once we complete the
    in-flight request

# Special cases

In order to maintain existing behaviour, we also handle a couple of
special cases:

  - if there is _only_ a single subscription request (inflight, or
    pending), and a duplicate request is submitted by the client, we
    just roll the callback into the existing request
  - if the next request is an unsubscribe, we will immediately call back
    if disconnected (but we no longer call them if there is a preceding
    subscribe waiting)

1429 of 1655 branches covered (86.34%)

71 of 71 new or added lines in 2 files covered. (100.0%)

3095 of 3179 relevant lines covered (97.36%)

537.87 hits per line