This is probably a duplicate of  issue 709  and/or  issue 705 .

I now have a tcpdump capture of the problem, but this time it did not result in an
exception (instead, it resulted in two reviews posted in close succession, where one
had a small subset of comments from the other). I cannot make that file available, as
it contains proprietary data, but I can answer questions about it.

I did notice that there were *two* (2) POSTs to the same URL for seemingly all of the
comments.

Digging further (into the capture, not the code):
1) enter a comment, hit save
2) a JSON post saves the comment
3) time passes... (more reviewing, commenting, etc.)
4) publish the review
5) every comment you have posted before is re-posted (same URL and post body as
before) as fast the browser, server, and network allows (mine covers 30 comments in
the span of 10 seconds)
6) less than 1 second after the final comment is posted again, the draft is published.

Factors that probably play a role for me:
1) I am on a LAN (high speed, low latency)
2) I am doing this testing at a low-usage time (the review server is idle)
3) I am using apache2 with the prefork MPM with: StartServers=5, MinSpareServers=5,
MaxSpareServers=10, MaxClients=150, MaxRequestsPerChild=0
4) I am working on a large review (about 40 files; at least that many comments;
comments ranging from one-liners to multi-paragraph ones)
5) I am composing that review over the course of an hour or two (so the server has
time to return to an idle state most of the time)

If the real fix is challenging, a short-term hack may be to have a new JSON API to
wait-until-draft-settled: given a review request (user+review_request pair to the
server), it will not return success until the draft has been idle for some specified
time window (client-specified, possibly hard-limited to 30 seconds to avoid abuse).

The algorithm might look something like (simplified for brevity):
1) gather state of the draft
2) wait until requested time elapses
3) gather state of draft
4) if draft state at 3 is different from draft state at 1, go to 1

This way, the attempt to publish will not go through until all in-flight comment
posts have completed.

An even simpler hack may be to simply make the client code pause for N seconds after
reposting the last comment before posting the publish command.

It seems a little surprising (to me) that the post-comment API would return before it
has been committed, but there may be complicating factors involved.

I've recently noticed this as well. We need to make this a priority for alpha 2.

Thanks for all the research on it. I'm going to go through later and see if I can get
a solid repro case and get this fixed.

So we're trying to be smart by setting up an asynchronous chain for the saves, so
that we save one comment at a time, wait for it to save, and then move on to the
next, and finally publish at the end.

Unfortunately, we're listening for when the inlineEditor's "complete" signal, which
doesn't mean we've saved to the server yet. So we end up with a race condition where
we're pushing all comment saves *and* publishing the review at the same time. The
solution is to have a custom signal emitted when we know the actual data has been
saved to the server.

This should be fixed now in r1703. Let me know if you still hit it.

Thanks!