4
\$\begingroup\$

This answer was posted at 2014-07-30 04:24:50Z, which is almost three hours after the question was closed at 2014-07-30 01:09:11Z.

This is the second time I've seen this. The first time a comment exchange followed along the lines of "how did you do that?" A: "bad site scripting I guess".

It seems like this happens when an answer is started when the question is opened, left for a while, and then submitted after it's closed. However it's happening, it's a significant bug that impairs the proper functioning of the site.

\$\endgroup\$
2
  • \$\begingroup\$ If someone remembers the other answer where this happened and could dig up the link, that'd be great. I think it was Brian asking how it happened; I don't remember whose answer it was or which of the recently-held questions it was. \$\endgroup\$
    – SevenSidedDie
    Jul 30, 2014 at 5:03
  • 1
    \$\begingroup\$ The other answer was this answer on this question, by a different user. Timeline: question closed 0:07, answer posted 0:34, deleted by Brian at 0:41, comment by Brian about being surprised at this even happening now gone. \$\endgroup\$
    – doppelgreener
    Jul 30, 2014 at 5:39

1 Answer 1

Reset to default
5
\$\begingroup\$

It's a feature of the system. See this question on Meta.SO from 2011: How was this answer posted after this question was closed?

In short: when a question gets closed, your client (as in: the browser, or the mobile app) will notice, tell you that you can't post an answer any longer, and the page will not cooperate in letting you do so. If your client doesn't notice, however, the Stack Exchange servers will still give you a grace period of about four hours to write your answer and submit it.

(This is probably totally abusable if you know how, but only if you're absolutely adamant to answer closed questions anyway, which is probably a waste of time and will eventually lead to us asking you to quit it.)

\$\endgroup\$
5
  • 1
    \$\begingroup\$ That is an unusual feature/policy and seems like it could easily be changed without UX harm even in the worst cases, but can't argue much with [status-bydesign]. So it's just that "but it should be freakishly rare" has coincidentally happened twice lately, not that there was a recent update that broke something. \$\endgroup\$
    – SevenSidedDie
    Jul 30, 2014 at 5:40
  • 1
    \$\begingroup\$ Huh, I didn't know this. I wonder how they keep it from being exploited... \$\endgroup\$
    – C. Ross
    Jul 30, 2014 at 11:09
  • 1
    \$\begingroup\$ @SevenSidedDie that's probably at least slightly related to an elevated closure rate of late (for a variety of reasons, most of them good). The more iterations, the more likely something rare happens... \$\endgroup\$
    – wax eagle
    Jul 30, 2014 at 12:55
  • 1
    \$\begingroup\$ @SevenSidedDie The main "UX harm" that seems to be avoided here is people not getting notified that they're wasting their time, so... if it's "close enough" the servers don't waste their time and just post it. Seems mostly harmless and saves some frustration for people it legitimately happens to. \$\endgroup\$
    – KRyan
    Aug 2, 2014 at 0:32
  • \$\begingroup\$ @KRyan Yeah, that's a good point, especially since it's much more likely to happen with long posts. \$\endgroup\$
    – SevenSidedDie
    Aug 2, 2014 at 0:35

You must log in to answer this question.

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