See User profile pages broken.

It is a bug report from 2017. At one point it was closed after being marked for the reason:

The problem described here can no longer be reproduced. Changes to the system or to the circumstances affecting the asker have rendered it obsolete. If you encounter a similar problem, please post a new question.

but reopened after. Currently, there are four close votes on it.

I don’t get it. When are we supposed to close bug reports for this reason? Couldn’t we close literally every resolved bug report with this reason? If not (as it apparently is), then what is special about some bug reports?

How is this to be used?


Both things (the tag and the close reason) indicate the same thing: the problem is solved, we don't expect new answers to the question, and it should not appear in the Unanswered tab. (As you can see, they do.)

IMHO, there is a difference: the is reserved for cases where somebody (usually Stack Exchange staff) had to actively do something in order to fix the (or implement the ). In this case, there's a comment by one of them:

We broke it, we're fixing it, someone will post an answer soon.

Posting that answer happened (sometimes, it doesn't, because the developers are too busy). We don't close programming problems on Stack Overflow just because they're solved; neither should we do here.

The close reason is for cases where it might have been solved accidentally, and is actually closer to :

Indicates that the site developers were not able to replicate the behavior reported.

The community here cannot add red tags; voting to close is the only option we have. It could be used for bugs about functionality that is long gone and might confuse new users, e.g. the accept rate. But (IMHO) not in the case you mention, and I apologize for having cast a close vote back then. I've learned quite a lot since ... (Note that it's possible that close votes have been cast before the edit, even though the closing itself took place afterwards.) I do have some sympathy for the close votes, since it's a short-lived bug probably caused by an easily-corrected mistake by one of the Stack Exchange developers, which makes it similar to the 'simple typographical error' close reason on Stack Overflow; it's unlikely to help future visitors.

At one point, I have considered asking a to disable this off-topic reason for questions marked with one of these tags, but it's probably too complicated to implement.

Final thought: since bugs and feature requests are moved off off Meta into The Loop, we can probably ditch the close reason (and hence this discussion) in 6-8 somethings...

  • 2
    I simply don't get why we are so eager to leave stuff open. It is resolved, no-one needs to be able to look back at that question ever again, no-one will be helped by its answers in the future or it must be for entertainment. Closing will help getting those questions roomba-ed. if only those rep hungry devs could refrain from answering ...
    – rene
    Nov 29 '19 at 7:27
  • 4
    @rene we don't close Stack Overflow questions because they're solved either... Oh, and one very minor point: closing a question affects Socratic badge progress.
    – Glorfindel Mod
    Nov 29 '19 at 7:34
  • 1
    @rene my problem is that it's unclear what the distinction between the tag no-repro and closing and just leaving it at status-completed is—I have been on Meta a lot for months and have no idea when to vote to close these things. Nov 29 '19 at 7:36

In your example the cause was that they "tried adding it to the read only routing list", the fix is that they know not to do that - so it's no-repro, one would not assume that they would do it again expecting no problems.

In a bug that I filed: Reputation not appearing in Rep. Notification Queue - yet it is given silently it was fixed but nothing was done to prevent a reoccurrence, and indeed it has reoccurred a few times (each referring to my earlier report):

After something is done that prevents it from ever occuring again then it's no-repro.

If we would assume in good faith that the person wouldn't make the same error once it has been explained then that too would be no-repro, as long as they understand, aren't forgetful, and are reliable.

Another way something can be no-repro is that someone reports a bug that doesn't reoccur and is unconfirmed. Such bugs don't get a . Especially old bugs, where the software or feature has markedly changed, that were never really resolved, are sometimes discovered and closed no-repro too.

You must log in to answer this question.

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