1. Open a Review Item (checked for Close queue @ SO)
  2. Add a comment to the post being reviewed
  3. Edit the comment => "An error occurred during comment submission" immediately

UPDATE: Despite having identified the case with audits in https://meta.stackexchange.com/a/270353/174091, I still encounter this sometimes in normal reviews. The cause is the same: real comment fns are being replaced by fakes. In particular, I see this happening when I browse back to the review that I've just voted on.

  • I can only enter the close queue again in 12 hours. I'll make a packet dump then. Dec 2, 2015 at 11:10
  • Can't repro in SO LQP queue. (Manual comment, not delete reason auto-comment.) Dec 3, 2015 at 3:37

3 Answers 3


I've (hopefully) fixed the bug when it occurs during non-audit situations.

As for audits, I think this was status-declined due to effort vs reward with how much work we wanted to put into making audits indistinguishable from real posts.

However, the current implementation is confusing, with its

An error occurred during comment submission

message, so next build will have that text change to

This is an audit

That should give the reviewer enough information to continue on and choose the correct path to pass the audit.

  • Isn't "This is an audit" defeating the purpose of audits? Nov 7, 2016 at 21:40
  • 1
    Not really, it means you're actually trying to engage with the poster and not just "robo-reviewing", which is what audits are meant to curtail. Nov 7, 2016 at 21:41
  • 1
    I.e. the act of adding a comment shows you're paying attention to the review and not just clicking an action as fast as you can. Nov 7, 2016 at 21:45

I've reproduced this - this time, it happened during comment addition.

Sniffer showed that no network requests are being made. Debugging JS showed that the culprit is these lines in review.en.js (auto-prettified):

var t = !0,
n = function (e, t) {
    StackExchange.helpers.showErrorMessage(t, 'An error occurred during comment submission')
    'submitNewComment': function () {
        n(this.jDiv.find('form[id^="add-comment-"]'), this.jDiv)
}, e), t),

This code overrides submitNewComment (and submitEdit just after the shown fragment) from full.en.js and, as you can see, the function indeed shows an error without POSTing anything.

  • I seem to have figured this out... but let's see what a developer has to say to... ahem... this. Dec 4, 2015 at 13:04
  • 1
    Still happens, more frequently in the last two weeks. I posted this bug report in Math.SE (adding Comments has become increasingly error prone) for a review that was not an audit (and a comment that successfully posted to the same Question outside the Review Queue).
    – hardmath
    Apr 13, 2016 at 1:44
  • @hardmath I wonder if it's another layer of Review Audits' disguise - a "false positive" this time. In meta.stackexchange.com/a/270353/174091, I taunted the developers for "sloppy work"... Looks like this was a BIG mistake. Apr 13, 2016 at 19:05
  • I've now gone several days without seeing these errors while submitting new Comments, omitting of course the "legitimate" errors for review audits. I think I got a couple of balky Comment edit submissions from review during this period, but not show stoppers. So likely some fix in the system software has occurred in the last ten days or so. Any evidence of a fix from your point of view?
    – hardmath
    Apr 22, 2016 at 14:19

Figured this out. This happens if the review is actually a review audit. (BUSTED! - Guys, sloppy work! :) )

The functions that control the comments are then replaced by fakes (see the previous answer for details).

I dunno how I managed to only run into this at editing stage. Maybe the overriding code was slow to load/execute, and I managed to submit a comment before it applied.

Still, I maintain this is a bug. The fact it's an audit is no reason to prevent me from doing any actions that are still valid:1

  • if it's a real post, comments should work as usual
  • if it isn't a real post, comments can still be faked to work. This can be detected by network activity or (if that is faked, too) submitting then reloading the page, but since an audit can be detected by simply pressing the question link anyway, this isn't much of a problem
    • given the scarcity of fake-post audits (I only ever saw those in suggested edits), there's little call for addressing the last case

1even less so disguise it as a bug. I'd even go to say: "The disguise was so perfect it became an actual bug!"


Not the answer you're looking for? Browse other questions tagged .