share / sharedb / 791

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`

364 of 442 branches covered (82.35%)

804 of 828 relevant lines covered (97.1%)

542.33 hits per line