share / sharedb / 792

97%

master: 97%

Pull #227

travis-ci

Fix flaky maxSubmitRetries test

This is a slightly speculative fix for a test that fails intermittently
on `sharedb-mongo`. I believe these intermittent failures are due to a
race condition in a concurrency test.

The test works by attempting to fire two commits off at the same time,
and hoping that one of them is committed just before the other, so that
a `SubmitRequest.retry` is triggered whilst the `maxSubmitRetries` is
set to `0`, resulting in an error that is expected.

However, I believe it's possible for these commits to (in some cases)
happen sequentially rather than concurrently, and fail to error.

This change attempts to force them into this retry condition by:

  - Catching both ops in the `commit` middleware, _just_ before they're
    about to be committed (and hit a `retry` if applicable)
  - Waiting until both ops have reached this state
  - Triggering the first op's `commit`
  - Then in the callback of that op, triggering the second op's `commit`
  - The second op should now find that the first op has beaten it to
    committing, and trigger a `retry`

1012 of 1203 branches covered (84.12%)

2118 of 2195 relevant lines covered (96.49%)

124.3 hits per line